Случай.
Строим облако для крупной компании Давно хотел рассказать вам о том, как мы строили облачное решение для одного из наших клиентов.
Итак, наш Заказчик — крупная международная компания с сотнями офисов по всему миру.
Основная инфраструктура сосредоточена в двух качественных дата-центрах в Европе и к ним нет претензий.
Но локальные компоненты в региональных офисах управляются многими региональными поставщиками услуг, и это создает кошмар на уровне управления как при непосредственном решении ИТ-задач, так и при контроле расходования ИТ-бюджета.
Заказчик решил, что перевод большей части некритичных региональных сервисов на Microsoft Azure позволит ему сэкономить на обслуживании своей ИТ-инфраструктуры, сосредоточить контроль над финансовыми расходами в центральном офисе и одновременно реализовать несколько проектов модернизации.
Мы уже внедрили гибридное решение Exchange на основе Office 365 с локальными компонентами для этого Заказчика в нескольких странах, где этого требовали правила, поэтому они обратились к нам и Microsoft с просьбой спроектировать и внедрить облачную платформу для размещения примерно 3000 серверов в течение 3-х лет. 3 года.
х лет. Все это произошло в конце 2015 — начале 2016 года и на данный момент платформа создана, и мы уже перенесли туда около 500 серверов.
Тема облаков в последнее время одна из самых популярных и существует довольно много документации и материалов, описывающих, что именно умеет тот или иной сервис и как его можно использовать.
Поэтому мы поговорим о другой стороне облаков — о том, с какими проблемами можно столкнуться на пути миграции вашей on-premise инфраструктуры.
Скорость обновления
Читая эту статью, у вас может сложиться ложное впечатление, что я критикую Azure. На самом деле это не так.Просто часть проблемы связана с тем, что этот облачный сервис очень активно и быстро развивается.
Это даже не особенность Azure, а общая особенность облаков.
Невозможно научиться делать что-то один раз и использовать это годами.
Вам придется постоянно учиться и развиваться.
И решения, которые вы продаете клиентам, также должны развиваться.
Трудно винить в этом Microsoft. Но это создает довольно много сложностей.
Помимо новых сервисов, о которых речь пойдет ниже, очень ярким примером является PowerShell. Работа с облаком требует высокой степени автоматизации операций.
Чем больше ваше окружение, тем более актуально это для вас.
Кроме того, некоторые операции вообще невозможно выполнить через графический интерфейс портала.
Обновления для Azure PowerShell выходят практически каждый квартал и очень часто существенно расширяют или изменяют функциональность командлетов (добавляются новые ключи, изменяются существующие, меняются типы возвращаемых объектов и т. д.).
Это значит, что вам нужно постоянно следить за всеми новостями, проверять работоспособность ваших скриптов после обновлений и смотреть, есть ли возможность сделать что-то проще или лучше.
У нас была забавная история, связанная именно с обновлением PowerShell. Наш инженер написал довольно большой кусок кода, чтобы добавить в командлет недостающий функционал по работе с виртуальными дисками.
А в начале следующей недели вышло обновление, в котором этот самый командлет получил новый параметр, делающий то же самое.
Это было одновременно приятно (ведь наше видение того, чего не хватает, совпало с продавцом) и немного грустно от потраченного времени.
Версии Azure
Причиной многих трудностей в конце 2015 года стало то, что облако Microsoft Azure активно переходило от Классические модели (Azure Service Management) на ARM (Azure Resource Management) .В каком-то смысле это можно назвать переходом от версии 1 к версии 2. Поскольку все инновации Azure ориентированы в первую очередь на ARM, Заказчик хотел, чтобы ARM-компоненты использовались повсеместно, кроме ситуаций крайней необходимости.
Это не говоря уже о том, что только ARM позволяет правильно настроить права доступа к различным компонентам в Azure в соответствии со стандартами предоставления ИТ-услуг.
Проблема заключалась в том, что в ARM на тот момент не было части функционала, который уже был доступен в Classic. Кроме того, совместная работа компонентов ARM и Classic была не всегда и не полностью возможна.
Это может показаться незначительным, ведь разные версии серверных операционных систем тоже имеют разный функционал и это нормально.
Разница здесь заключалась в том, что скорость разработки облачных сервисов гораздо выше и архитекторы, работавшие над этим проектом с нашей стороны, привыкли говорить о решениях на базе Azure, основанных на классической функциональности, полагая, что новые версии компонентов могут как минимум это сделать.
все тоже самое.
Более того, как оказалось, такие же трудности испытывают и архитекторы Microsoft.
Сеть
Расширение ИТ-инфраструктуры клиента в облако начинается с сети.Ваша первая задача — создать сети в облаке и подключить их к существующей инфраструктуре.
Здесь нас ждал первый сюрприз.
Оказалось, что топология виртуальной сети, предложенная архитектором Microsoft на начальном этапе проекта, была основана на идее о том, что две виртуальные сети Azure могут существовать в одной виртуальной сети Azure. Виртуальный сетевой шлюз — один для подключения ExpressRoute, другой — для VPN между виртуальными сетями.
Идея заключалась в том, чтобы обеспечить дополнительную изоляцию внутренних сетей заказчика от трафика из DMZ. Как оказалось, ARM этого не позволяет. Нам пришлось на лету перейти к возможности подключения всех виртуальных сетей к одному ExpressRoute, чтобы обеспечить маршрутизацию между ними, и к пользовательской маршрутизации для обеспечения безопасности.
Еще одной неприятной особенностью работы с виртуальной сетью стало ограничение количества правил в одной группе безопасности сети (NSG).
Здесь необходимо отметить несколько технических аспектов работы сети в Azure, каждый из которых по отдельности доставлял лишь незначительное неудобство, но вместе они становились проблемой:
- В одной группе безопасности сети нельзя создать более 500 правил.
- Большой А Часть функциональности виртуальных машин в Azure требует доступности.
IP-адреса общедоступных служб Microsoft на портах 80 и 443. Microsoft регулярно обновляет и публикует этот список.
На данный момент для некоторых регионов он уже содержит несколько сотен адресов.
- Правила NSG можно создавать для последовательного диапазона адресов или портов, но не для случайного набора.
То есть трафик на порты 80-443 можно открыть одним правилом, но если вы хотите именно 80 и 443, без ничего между ними, то вам понадобятся два правила (та же история и для IP-адресов).
К счастью, эта проблема скоро уйдет в прошлое — Microsoft объявила об изменениях в NSG, которые позволят добиться большей гибкости в работе с правилами.
Ограничения
Раз уж мы затронули вопрос квот в Azure (500 правил на NSG), стоит отметить, что они сами по себе являются головной болью, если у вас большой проект. Спектр сервисов Azure постоянно расширяется и, что вполне логично, имеет свои ограничения.Проблема в том, что нет оборудования, позволяющего просмотреть все ограничения в одном месте.
То есть вам придется полагаться на целую мешанину отдельных команд, собирающих для вас информацию, и нескольких веб-страниц с перечислением текущих лимитов.
Это, конечно, не очень удобно.
Особенно когда всплывает какой-то неожиданный лимит, о котором вы не подумали заранее.
Хранилище данных
Одним из примеров довольно сложной квоты, о которой не все задумываются, является производительность ресурса, такого как учетная запись хранения .Дело в том, что VHD-диск в Standard Storage для большинства размеров виртуальных машин имеет максимальную производительность 500 IOP, но сама Storage Account имеет 20 000 IOP. При этом максимальный размер диска составляет 1023 ГБ, а максимальная емкость учетной записи хранения — 500 ТБ.
Вы уже понимаете, в чем здесь подвох? Когда вы размещаете на одном Storage Account 41 диск, то теоретически можете оказаться в ситуации, когда при максимальной нагрузке на все диски их производительность начинает искусственно ограничиваться.
При этом вы еще не заняли и 10% от максимальной емкости, и каждый последующий диск будет только ухудшать ситуацию.
Самое неприятное, что система никак вас об этом не предупредит. Вы узнаете об этом только в том случае, если заранее подумаете о таких вещах и либо не размещаете более 40 дисков на одной Storage Account, либо следите за Throttling с его стороны и при активации перемещаете активно используемые диски в другое место.
Учитывая, что развертывание ваших серверов, скорее всего, автоматизировано, вам необходимо подумать о том, как ваши инструменты автоматизации будут выбирать, где размещать виртуальные диски, особенно если теоретически возможно одновременно запускать несколько развертываний серверов.
Торговая площадка
Забавно, но одной из сложностей при работе с Azure является и ее главное преимущество — обширный Маркетплейс.Множество сервисов и постоянное расширение списка доступных услуг - это очень круто.
Проблема в том, что при таком разнообразии разработчики физически не могут протестировать взаимодействие своего продукта с другими, и если вы начнете использовать его сразу после релиза, вы можете быть первым, кто сделает это именно для той комбинации, которую вы используете.
Вот пара интересных примеров:
- Сразу после выхода Azure Site Recovery (сервиса для защиты ваших серверов путем их репликации в облако) потребовалось открыть весь трафик на портах 443 и 80 в Интернет для выполнения Failover сервера, поскольку список адресов для этот сервис еще не был добавлен в Белый список Azure (понятно, что это очень быстро исправили, но одно время мы ломали над этим голову).
- Многие функции виртуальных машин в Azure привязаны к расширениям виртуальных машин.
Например, шифрование и резервное копирование.
Существует множество операций, которые очищают набор расширений для виртуальной машины.
Причем это достаточно часто используемые операции, такие как развертывание сервера с VHD (основной метод решения многих проблем с серверами и обязательный этап при их переносе между группами ресурсов) или даже восстановление сервера из Azure VM Backup. Несмотря на это, удобного инструмента для хранения списка этих расширений не существует и вам придется делать это самостоятельно.
Заключение
Какую идею вы хотели донести в этой статье? Лично я далек от мысли, что облака полностью заменят локальную инфраструктуру в обозримом будущем, но надеяться, что от них удастся спрятаться, довольно глупо.Но это не обязательно! Работать с Azure очень интересно.
Если вам нравится постоянно узнавать что-то новое, следить за появлением новых функций и смотреть, что можно использовать для улучшения своих решений, то вы не будете разочарованы.
P.S. Те из вас, кто работает с Azure, могут заметить, что большинство проблем, описанных в этой статье, больше не актуальны.
Microsoft очень активно следит за отзывами сообщества и совершенствует свои сервисы (хотя история с NSG до сих пор не исправлена!).
Теги: #microsoft #Microsoft Azure #it инфраструктура #Системное администрирование #Администрирование серверов #облачная инфраструктура #облачные технологии #облако #облачная платформа
-
Ваш Первый Шаг В Науке О Данных. Титаник
19 Oct, 24 -
Кодирование Звука С Потерями. Что Есть Что?
19 Oct, 24 -
Еще Один Планшет Irobot
19 Oct, 24 -
Внешнее Соединение В Linq
19 Oct, 24 -
Подкаст Appleinsider [05]
19 Oct, 24
