Кейс. Строим облако для крупной компании

Мне давно хотелось рассказать, о том как мы строили облачное решение для кого-нибудь из наших заказчиков.


Итак, наш Заказчик — крупная международная компания, с сотнями офисов по всему миру. Основная инфраструктура сосредоточена в двух высококлассных ЦОД в Европе и к ним никаких претензий нет. А вот локальные компоненты в региональных офисах управляются множеством региональных поставщиков услуг, и это порождает кошмар на уровне менеджмента как с решением непосредственно ИТ-задач, так и в контроле за расходованием ИТ-бюджета. Заказчик решил, что перенос большей части некритичных региональных сервисов в Microsoft Azure позволит ему сэкономить на обслуживании своей ИТ инфраструктуры, сосредоточить контроль за расходованием финансов в центральном офисе и, заодно, реализовать несколько проектов модернизации. Мы уже внедряли для этого Заказчика гибридное Exchange решение на базе Office 365 с локальными компонентами в нескольких странах, где этого требовали нормы законодательства, так что он обратился к нам и к Microsoft за проектированием и внедрением облачной платформы для размещения примерно 3000 серверов в течение 3-х лет.

Всё это происходило в конце 2015 — начале 2016 и, на данный момент, платформа создана, и мы уже мигрировали туда около 500 серверов. Тема облаков одна из самых популярных в последнее время и существует довольно много документации и материалов, описывающих, что именно умеет тот или иной сервис и как вы можете его использовать. Поэтому мы поговорим о другой стороне облаков — о том, какие проблемы можно встретить на пути переноса вашей on-premises инфраструктуры.

Скорость обновлений

В ходе чтения этой статьи у вас может сложиться ложное ощущение, что я ругаю Azure. На самом деле, это не так. Просто часть проблем связана с тем, что этот облачный сервис очень активно и быстро развивается. Это даже не особенность Azure, а общая черта облаков. Здесь не получится один раз научиться что-то делать и пользоваться этим годами. Учиться и развиваться придётся постоянно. И решения, которые вы продаете Заказчикам, также должны развиваться. Это сложно поставить в упрёк Microsoft. Но сложностей это создаёт изрядно.

Помимо новых сервисов, о которых ниже, очень ярким примером является PowerShell. Работа с облаком предполагает высокую степень автоматизации операций. Чем больше ваша среда, тем актуальнее это для вас. Кроме того, некоторые операции вообще нельзя сделать через GUI портала. Обновления для Azure PowerShell выходят почти каждый квартал и очень часто они существенно расширяют или меняют функционал командлетов (добавляются новые ключи, меняются существующие, меняются типы возвращаемых объектов и т.д.). Это значит, что нужно постоянно следить за всеми новостями, проверять функциональность ваших скриптов после обновлений, смотреть не появилось ли возможности сделать что-то проще или лучше.

У нас была весёлая история, связанная именно с обновлением PowerShell. Наш инженер написал довольно большой кусок кода, чтобы добавить недостающую функциональность командлету для работы с виртуальными дисками. А в начале следующей недели вышло обновление, в котором этот самый командлет получил новый параметр, который делал ровно то же самое. Было и приятно (всё-таки наше видение того, чего не хватает совпало с вендором) и немного грустно за потраченное время.

Версии Azure

Причиной многих сложностей в конце 2015 года было то, что облако Microsoft Azure активно переходило с Classic (Azure Service Management) модели на ARM (Azure Resource Management). В каком-то смысле, это можно назвать переходом с версии 1 на версию 2. Так как все нововведения Azure прежде всего ориентированы на ARM, то Заказчик хотел, чтобы везде, кроме ситуаций исключительной необходимости, были использованы ARM компоненты. Это уже не говоря о том, что только ARM даёт возможность нормально настраивать права доступа к различным компонентам в Azure в соответствии со стандартами предоставления ИТ-услуг. Проблема была в том, что в ARM на тот момент не было некоторой части функционала, который уже был доступен в Classic. Кроме того, совместная работа ARM- и Classic- компонентов была возможна далеко не всегда и не полностью.

Это может показаться незначительным, в конце концов, разные версии серверных операционных систем тоже обладают разным функционалом и это нормально. Здесь отличие было в том, что скорость развития облачных сервисов значительно выше и архитекторы, работавшие над этим проектом с нашей стороны, привыкли рассуждать о решениях на базе Azure опираясь на Classic-функционал, полагая, что новые версии компонентов умеют, как минимум, всё тоже самое. Причём, как оказалось, те же сложности испытывают и архитекторы Microsoft.

Сеть

Расширение ИТ-инфраструктуры заказчика в облако начинается с сети. Ваша первая задача — создать сети в облаке и связать их с существующей инфраструктурой.


Именно здесь нас поджидал первый сюрприз. Выяснилось, что топология виртуальной сети, которую предложил архитектор из Microsoft на начальном этапе проекта, основывалась на идее о том, что в одном Azure Virtual Network могут существовать два Virtual Network Gateway — один для ExpressRoute-соединения, другой для Vnet-to-Vnet VPN. Идея была — обеспечить дополнительную изоляцию внутренних сетей заказчика от траффика из DMZ.

Как оказалось, ARM такого не позволял. Нам пришлось на ходу переходить на вариант подключения всех VNET к одному ExpressRoute, чтобы получить маршрутизацию между ними и User Defined Routing, чтобы обеспечить безопасность.

Ещё одной неприятной особенностью работы с виртуальной сетью оказалось ограничение на количество правил в одной Network Security Group (NSG). Здесь нужно отметить несколько техническим моментов работы сетей в Azure, каждый из которых, по отдельности, являлся лишь небольшим неудобством, но вместе они стали проблемой:

• Вы не можете создать более 500 правил в одной NSG.
• Большая часть функционала для виртуальных машин в Azure требует доступности IP адресов публичных служб Microsoft по портам 80 и 443. Microsoft регулярно обновляет и публикует этот список. На данный момент для некоторых регионов в нём уже несколько сотен адресов.
• Правила NSG могут создаваться для последовательного диапазона адресов или портов, но не для произвольного набора. То есть, вы можете открыть одним правилом трафик на порты 80-443, но если вы хотите именно 80 и 443, без того, что между ними, то вам потребуются два правила (та же история для IP адресов).

В результате, нам не только нужно было подготовить скрипты для автоматического обновления наших NSG-правил (ведь не могли же мы руками переделывать их каждую неделю?), но, что хуже, у нас оставалось не так много правил для использования по прямому назначению — контролю за трафиком между нашими сетями.

К счастью, эта проблема скоро уйдёт в прошлое — Microsoft анонсировала изменения в NSG, которые позволят более гибко работать с правилами.

Ограничения

Раз уж мы коснулись вопроса квот в Azure (500 правил на одну NSG), то стоит отметить, что они сами по себе являются головной болью, если у вас большой проект. Набор сервисов в Azure постоянно расширяется и, вполне логично, что у них есть свои ограничения. Проблема в том, что нет никакой оснастки позволяющей посмотреть все ограничения в одном месте. То есть, вам приходится полагаться на целую солянку из отдельных команд, собирающих вам информацию и несколько веб-страниц с перечислением текущих лимитов. Это, конечно, не очень удобно. Особенно, когда всплывает какой-нибудь неожиданный лимит, о котором вы не подумали заранее.

Хранение данных

Один из примеров довольно хитрой квоты, о которой задумываются далеко не все является производительность такого ресурса как Storage Account. Дело в том, что VHD диск на Standard Storage для большинства размеров виртуальных машин имеет максимальную производительность в 500 IOPs, а вот сам Storage Account — 20,000 IOPs. При этом, максимальный размер диска — 1023GB, а максимальная ёмкость Storage Account — 500TB. Вы уже видите, в чём здесь подвох? Когда вы разместите на одном Storage Account 41 диск, вы уже теоретически можете оказаться в ситуации, когда при максимальной загрузке всех дисков их производительность начнёт искусственно ограничиваться. При этом вы ещё не заняли и 10% от максимальной ёмкости и каждый следующий диск будет делать ситуацию только хуже.

Самое неприятное, что система вас об этом никоим образом не предупредит. Вы узнаете об этом только если подумаете о таких вещах заранее и либо не размещали больше 40 дисков на один Storage Account либо мониторите Throttling с его стороны и при его активации перемещаете активно используемые диски в другое место.

Учитывая, что развертывание серверов у вас, скорее всего, автоматизировано, вам нужно продумать, как ваши средства автоматизации будут выбирать место расположения виртуальных дисков, особенно, если теоретически возможен запуск одновременного развёртывания множества серверов.

Marketplace

Забавно, но одна из сложностей при работе с Azure является и её главным достоинством — обширный Marketplace. Множество сервисов и постоянное расширение списка доступных услуг — это очень здорово. Проблема в том, что при таком разнообразии разработчики физически не могут проверить взаимодействие своего продукта с другими и, если вы начинаете его использовать сразу после релиза, возможно, вы будете первым, кто это сделает именно для той комбинации, что используется у вас.


Здесь можно привести пару интересных примеров:

• Сразу после релиза Azure Site Recovery (сервис для защиты ваших серверов путём их репликации в облако) он требовал открыть весь трафик по 443 и 80 портам в интернет для проведения Failover сервера, потому что список адресов для этого сервиса еще не был добавлен в Azure Whitelist (понятно, что это очень быстро поправили, но голову мы над этим, в своё время, поломали).
• Многие функции виртуальных машин в Azure завязаны на VM Extensions. Например, шифрование и резервное копирование. Есть множество операций, очищающих набор Extensions для виртуальной машины. Причём, это довольно часто используемые операции, такие как, развёртывание сервера из VHD (основной метод решения многих проблем с серверами и обязательный шаг при переносе их между Resource Group) или даже восстановление сервера из Azure VM Backup. Несмотря на это, нет удобного инструмента для сохранения списка этих Extensions и вам придётся делать его самим.

Заключение

Какую мысль хотелось донести в этой статье? Лично я далёк от мысли о том, что облака в обозримом будущем полностью заменят on-premises инфраструктуру, но и надеяться, что вам удастся от них спрятаться, довольно глупо. Но это и не нужно! Работать с Azure очень интересно. Если вам нравится постоянно учиться новому и следить за выходом нового функционала, прикидывая, что из него вы сможете использовать, чтобы улучшить свои решения, то вы не будете разочарованы.

P.S. Те из вас, кто работает с Azure, могут заметить, что большая часть тех проблем, что описаны в этой статье, уже не актуальны. Microsoft очень активно следит за обратной связью комьюнити и дорабатывает свои сервисы (правда, историю с NSG до сих пор не поправили!).