Главная » Блоги Экспертов И ИТ-Компаний » Как мы строили облачную инфраструктуру в Azure
ICL Services – центр компетенций по цифровизации бизнеса: https://youtu.be/MXjxVJqZjVA 1 год назад

Как мы строили облачную инфраструктуру в 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 модели на ARM. В каком-то смысле, это можно назвать переходом с версии 1 на версию 2. Так как все нововведения Azure прежде всего ориентированы на ARM, то Заказчик хотел, чтобы везде, кроме ситуаций исключительной необходимости, были использованы ARM компоненты. Это уже не говоря о том, что только ARM даёт возможность нормально настраивать права доступа к различным компонентам в Azure в соответствии со стандартами предоставления ИТ-услуг. Проблема была в том, что в ARM на тот момент не было некоторой части функционала, который уже был доступен в Classic. Кроме того, совместная работа ARM- и Classic- компонентов была возможна далеко не всегда и не полностью. 

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

Продолжение кейса в нашем блоге на Хабрахабр.


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Казань
www.icl-services.com, PR-менеджер
Информационные технологии

ICL Services — международный центр компетенций по цифровизации бизнеса. На сегодняшний день это одна из крупнейших ИТ-сервисных компаний России с более 1400 сотрудников, успешно работающих с более чем восьмьюдесятью клиентами из 30 стран мира.

ICL Services обеспечивает бесперебойную работу ИТ-инфраструктуры заказчиков 24/7 дней в неделю 365 дней в году.

Компания входит в ТОП-100 лучших аутсорсинговых компаний мира по версии IAOP, ТОП-10 крупнейших поставщиков услуг ИТ-поддержки по версии CNews, Лауреат премии «Время инноваций – 2017» в номинации «Продукт года» в категории «IT и цифровые технологии».




Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>