Рекомендации по инфраструктуре для облачных вычислений

Введение
Поскольку тенденция облачных вычислений продолжает набирать обороты, вполне вероятно, что вы в конечном итоге рассмотрите возможность передачи некоторых своих ИТ-операций на аутсорсинг поставщику облачных услуг. Однако прежде чем вы это сделаете, важно понять, что облако сопряжено с совершенно новым набором проблем, с которыми вы, возможно, не столкнетесь в традиционном локальном центре обработки данных. Поскольку некоторые из этих проблем связаны с вашей сетевой инфраструктурой, я хотел бы воспользоваться возможностью, чтобы поговорить о том, как использование облачных сервисов может повлиять на вашу сетевую инфраструктуру.
Соглашения об уровне обслуживания
Большинство крупных организаций налагают на свой ИТ-персонал соглашения об уровне обслуживания (SLA) для критически важных приложений. Например, организация может иметь SLA, требующее, чтобы электронная почта была доступна 99,999% времени. Это так называемое «пять девяток доступности» означает, что служба может быть недоступна не более пяти минут в год.
Я хочу сказать, что если вы связаны строгим соглашением об уровне обслуживания для ваших критически важных приложений, то не в ваших интересах передавать эти приложения в облако. Причина проста. Ни один поставщик облачных услуг не может гарантировать, что ваше соглашение об уровне обслуживания будет выполнено.
Не поймите меня неправильно. Некоторые поставщики облачных услуг соглашаются соблюдать соглашения об уровне обслуживания. Однако в конечном счете шансы на то, что провайдер действительно сможет соблюдать SLA, нереальны. В конце концов, ваша организация будет подключаться к поставщику услуг через Интернет. Ни вы, ни поставщик облачных услуг, ни ваш интернет-провайдер не контролируете весь Интернет. Даже если поставщик облачных услуг может обеспечить 100-процентную доступность размещенного приложения, сбой в Интернете может сделать приложение недоступным. Если вы прочтете мелкий шрифт в SLA облачного провайдера, то, скорее всего, будет сказано, что облачный провайдер не несет ответственности за перебои в работе Интернета.
Резервирование Интернета
В предыдущем разделе я объяснил, как сбой в Интернете может сделать размещенное приложение или службу недоступными. В настоящее время невозможно полностью избежать сбоев в работе Интернета, но иногда вы можете использовать избыточность как средство снижения вероятности сбоя, связанного с Интернетом.
Конечно, просто иметь несколько подключений к Интернету недостаточно. Ключом к достижению эффективной избыточности является приобретение интернет-услуг у нескольких поставщиков. Предположим, например, что у вас есть два отдельных широкополосных соединения от одного и того же интернет-провайдера. Если у этого провайдера произошел сбой, то сбой, скорее всего, затронет оба ваших интернет-соединения, что полностью сведет на нет цель наличия избыточных интернет-соединений.
В некоторых случаях может быть невозможно получить доступ в Интернет от нескольких провайдеров. В таких ситуациях вы должны подумать, следует ли вам передавать что-либо в облако. Например, я живу в сельской местности, которую обслуживает один интернет-провайдер «мама и папа», обладающий монополией на всю территорию. Я не смог бы получить услуги от второго поставщика, даже если бы захотел. Хотя я мог получить избыточные подключения от моего текущего интернет-провайдера, мой интернет-провайдер отключается примерно раз в неделю. Таким образом, я должен был бы сойти с ума, чтобы передать что-то важное в облако.
По общему признанию, больше всего меня останавливает от использования облака то, что мой интернет-провайдер не очень надежен. Но что, если вы находитесь в ситуации, когда ваш интернет-провайдер надежен, но вы не можете получить услуги от вторичного интернет-провайдера?
В такой ситуации избыточность все еще может быть полезной, даже если вы можете получать услуги только от одного интернет-провайдера. Если у вас есть избыточные подключения к Интернету от одного поставщика услуг, эти подключения не защитят вас в случае сбоя вашего интернет-провайдера. Однако это поможет защитить вас от аппаратного сбоя. Например, если Интернет-маршрутизатор в вашей сети выйдет из строя, сетевые узлы все равно смогут получить доступ к Интернету через резервное соединение.
Задержка
Еще один фактор, который необходимо учитывать при рассмотрении вопроса о том, стоит ли передавать услуги в облако, — это неотъемлемая (и непредсказуемая) задержка, возникающая при использовании службы через Интернет.
В последнее время многие организации используют облачное хранилище. Это дает им неограниченный пул хранения по запросу. Хотя нельзя отрицать преимущества, которые может предоставить облачное хранилище, также стоит отметить, что облачное хранилище в настоящее время не обеспечивает тот же уровень производительности, который доступен через локальные решения для хранения. Кроме того, поскольку пул хранения находится в Интернете, задержка несколько непредсказуема.
Чтобы дать вам лучшее представление о том, что я имею в виду, рассмотрим мою собственную ситуацию. Я работаю вне дома, и большую часть времени мое подключение к Интернету работает достаточно хорошо. Однако ближе к вечеру я всегда замечаю, что мое интернет-соединение становится медленнее, когда мои соседи начинают возвращаться домой с работы. Иногда производительность снижается до такой степени, что мое соединение становится непригодным для использования.
Конечно, я работаю дома, но та же проблема может возникнуть и в корпоративной среде. Такие факторы, как то, что пользователи делают в данный момент, и общая емкость вашего интернет-провайдера, могут привести к колебаниям производительности Интернета, и эти колебания могут напрямую привести к задержке, если вы подключены к пулу облачных хранилищ.
Программное обеспечение на стороне клиента
Последнее требование к инфраструктуре, о котором я хочу упомянуть, — это программное обеспечение на стороне клиента. Если вы используете облако только для инфраструктуры как услуги (IAAS), как в случае с облачным хранилищем, то клиентское программное обеспечение не является проблемой. Однако, если вы на самом деле размещаете приложения в облаке, программное обеспечение, которое клиенты используют для взаимодействия с этими приложениями, должно быть надежным.
Например, я знаю человека, который решил использовать Microsoft Office Web App вместо того, чтобы платить за лицензирование Microsoft Office 2010 на всех своих ПК. Если вы не знакомы с Office Web App, это набор бесплатных веб-версий приложений Microsoft Office. Эти приложения предназначены для доступа через веб-браузер.
Короче говоря, человек, о котором идет речь, в конечном итоге посетил вредоносный веб-сайт, который использовал вирус для отключения Internet Explorer. Это привело к тому, что они потеряли доступ не только к Интернету, но и к основным приложениям для повышения производительности, которые они используют каждый день.
Несмотря на то, что это событие произошло не в корпоративной среде, оно вполне могло произойти. Не все облачные приложения основаны на браузере, но некоторые из них. Независимо от того, основано ли облачное приложение на браузере или нет, очень важно принять меры для сохранения целостности любого программного обеспечения, которое клиентские компьютеры используют для доступа к размещенному приложению.
Вывод
В этой статье я объяснил, что, несмотря на преимущества использования облачных сервисов, размещенные сервисы создают ряд проблем, которые часто отличаются от тех, с которыми можно столкнуться при локальном развертывании. Таким образом, важно предвидеть как можно больше из этих проблем и соответствующим образом планировать, прежде чем начать аутсорсинг ресурсов в облаке.