Как мы строили облачную инфраструктуру в Azure

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


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


    Итак, наш Заказчик — крупная международная компания, с сотнями офисов по всему миру. Основная инфраструктура сосредоточена в двух высококлассных ЦОД в Европе и к ним никаких претензий нет. А вот локальные компоненты в региональных офисах управляются множеством региональных поставщиков услуг, и это порождает кошмар на уровне менеджмента как с решением непосредственно ИТ-задач, так и в контроле за расходованием ИТ-бюджета. Заказчик решил, что перенос большей части некритичных региональных сервисов в 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 до сих пор не поправили!).
    ICL Services
    94.92
    Цифровые технологии для бизнеса
    Share post

    Comments 22

      0
      Я так понимаю, что большинство проблем от того, что масштаб облака Azure не поспевает за требуемой вычислительной мощностью и пропускной способностью?
      Хорошо у Майков похоже дела идут, как они не успевают планки памяти вставлять и править конфиги.
        0
        Видимо, вы не очень внимательно читали. Ни одна из проблем не была связана с нехваткой мощности или пропускной способности:)

        Основная причина проблем — сложно работать со столь быстро развивающимся продуктом. Иногда, сложно обеим сторонам и нам и МС.

        А так, да, хорошо идут. Azure, вроде, очень неплохо продаётся.
          0
          Как невнимательно, тут половина недостатков — это какие-то квоты.
            0
            Но эти квоты не динамические. Они же какие-то ограничения должны задавать при установке цены. Так что квота сама по себе не проблема.

            Поблема в том, как, иногда, неожидано в эти квоты упираешься или как они друг с другом или с функционалом взаимосвязаны.
        0
        del
          0
          «Терминология отделяет нас от непосвященных».

          Зачем использовать вот это все:

          «облака в обозримом будущем полностью заменят on-premises инфраструктуру»,
          «Многие функции виртуальных машин в Azure завязаны на VM Extensions»,
          «её главным достоинством — обширный Marketplace»,
          «Когда вы разместите на одном Storage Account»

          Неужели для этих слов нет не менее простых и понятных русскоязычных аналогов? Не говоря уже о том, что в правилах хорошего тона хотя бы один раз в статье расшифровывать краткие сокращения (ARM, NSG).
            0

            Вы Xbox, PlayStationб Steam и подобное тоже будете пытаться переводить?
            Термины и названия продуктов очень часто не перводят ибо нет смысла и только запутает.

              0
              Названия продуктов не переводяться. А вот написать, что сокращение ARM — это Azure Resource Management, а не тип процессора стоило. Ну или обозначить, что входит в аббревиатуру NSG (чтобы было понятно, что это не какой-то вендор NSG, который что-то делает для азуры). Обозначенные мной в комментарии выше фразы также легко переводяться на русский язык и обратно без потери смысла.
                0

                Сокращения легко гуглятся при необходимости, но для удобства можно было, конечно, один раз раскрыть.
                Признайтесь у вас абсолютно все интерфейсы на русском? Перевод консоли тоже установили на оборудование? Кстати, слово "интерфейс" не хотите перевести?

                  +1
                  Помимо слова «интерфейс», существует также тысячи других заимствованных слов как «джинсы», «шорты», «маркетинг», «импичмент», «футбол» и так далее. И я очень рад, что никому не приходит в голову писать тексты используя англоязычные аналоги этих слов: «я сегодня надел свои jeans, съел cheaps и пошел играть в football».

                  Для тех же слов, которые еще не стали заимствованными, или же для специализированных сокращений в научно-популярных статьях (коей является статья выше) желательно использовать или их русскоязычные аналоги или давать в тексте расшифровку. К примеру, в рамках данной статьи было бы приятнее увидеть нечто вида: «Вы не можете создать более 500 правил в одной группе безопасности сети (Network Security Group, далее — NSG)».

                  Когда же автор публикации во всю использует терминологию, не давая ее расшифровки, у меня лично складывается ощущение, что автор не разбирается в предмете публикации.
                    0
                    Спасибо за замечание. Я обычно стараюсь расшифровть. Здесь проблема была в том, что русские названия многих компоненто очень сбивают с толку.

                    Постараюь лучше расшифровывать термины при использовании.
                      –1
                      Здесь проблема была в том, что русские названия многих компоненто очень сбивают с толку.

                      Они сбивают с толку, только если вы в них ничего не понимаете. Если бы вы в предмете разбирались, то статью можно было бы сделать куда более интересной. У вас же все свелось к перечислению услышанных от инженеров фактов.
                        0
                        Вот сейчас было обидно.

                        Я оставлю на вашей совести утверждение о том, что, если я предпочитаю английские названия русским, то я ничего не понимаю в предмете. А на своей — нелюбовь к руским терминам.
              0
              Про ARM и Classic согласен. Поправил.

              Storage Account, VM Extension, Marketplace не переводились специально, чтобы не путать. Я могу подобрать адекватный русский перевод, но зачем? Если человек захочет найти о чём шла речь, то ему комфортнее будет работать с оригинальными названиями.
                0
                Если человек захочет найти о чём шла речь, то ему комфортнее будет работать с оригинальными названиями.

                То есть вы статьи пишете не для того, чтобы их читали, верно?

                Некоторые текстовые франкенштейны меня удивляют:
                облака в обозримом будущем полностью заменят on-premises инфраструктуру.


                Почему «облака», а не cloud инфраструктура тогда уж? Ну или если пишите «облака», то заменяйте слово «on-premises инфраструктура» на «собственная инфраструктура» — это как-то проще и понятнее будет, не так ли?
                  0
                  То есть вы статьи пишете не для того, чтобы их читали, верно?

                  Я имел ввиду, что искать информацю по «Storage Account» удобне чем по «Учетой Записи Хранения» (не говоря уже о том, что «Учетная Запись Хранения» для моего уха звучит гораздо большим франкенштейном).

                  Почему «облака», а не cloud инфраструктура тогда уж? Ну или если пишите «облака», то заменяйте слово «on-premises инфраструктура» на «собственная инфраструктура» — это как-то проще и понятнее будет, не так ли?

                  «Cloud» и «Облако» как синонимы исользуются очень часто, а вот «on-premises» и «собственная инфраструктура» нет (это легко проверить, просто введя эти термины в поисковик). Это каждый раз большая внутренняя борьба для меня. Между Облаком и Cloud я, кстати, выбирал очень долго.
                    0
                    Я имел ввиду, что искать информацю по «Storage Account» удобне чем по «Учетой Записи Хранения» (не говоря уже о том, что «Учетная Запись Хранения» для моего уха звучит гораздо большим франкенштейном).

                    А я имел ввиду, что лучше, когда из статьи понятно что такое Storage Account и не приходится дополнительно гуглить, чтобы разобраться в вопросе.
                      0
                      Тогда к статье должен прилагаться глоссарий. Потому что «Учетная запись хранения» тоже не объясняет, что это такое. Я всё-таки предполагаю, что, если вы читаете статью про Azure, то базовыми терминами вы владеете.
                        0
                        Я всё-таки предполагаю, что, если вы читаете статью про Azure, то базовыми терминами вы владеете.

                        Я точно также предполагаю, что если человек пишет статью про Azure, то базовыми терминами он владеет. И о я очень расстраиваюсь, когда выясняется, что человек не может объяснить что означают те или иные базовые вещи.
                          0
                          Не может и не объяснил в тексте этой же статьи это несколько разные вещи, согласитесь.
              0

              Вот этого клиенты и не любят:


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

              Only users with full accounts can post comments. Log in, please.