Инженерная инфраструктура центров обработки данных (ЦОД)

Наши аналитики считают, что 70% ИТ руководителей в настоящий момент обеспокоены вопросами перехода к облачным технологиям. Одни руководители просматривают возможность как с себя убрать нагрузку, передать в аутсорсинг, в те самые облачные вычисления. Другие, наоборот, рассматривают возможность, а как бы так сделать, чтобы внутри предприятия, организации или какой-то инфраструктуры появился тот самый заветный облачный ресурс, чтобы предоставлять услуги остальным участникам IT-рынка и на этой зарабатывать деньги. И тот, и другой подход, и тот и другой план, он, конечно, требует определенных усилий и определенной информации. Я сейчас как раз бы хотел бы посмотреть, что нужно рассмотреть в том случае, если Вы заинтересованы в строительстве такого облачного ЦОДа.

На чем же его нужно строить облако?

Понятно, что нужно обязательно определиться с серверным оборудованием, источниками бесперебойного питания, горячим и холодным коридором, с выбором памяти и т.п. Я понял, что с системой пожаротушения уже определяться не нужно, мы знаем, что там будет стоять. Но потом возникает резонный вопрос: как получать пользу из того, что мы построили? На чем будет работать тот самый заветный облачный ЦОД? Давайте сначала определимся, что из себя представляет облачная инфраструктура и почему об этом мы сейчас начинаем разговаривать?

Облачная инфраструктура

     Дело все в том, что просто предоставить вычислительные мощности даже большому, крупному потребителю на сегодняшний день недостаточно. Эти мощности должны отвечать целому набору параметров.

Необходимо предоставлять пользователю сервисы

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

Для облака необходима автоматизация

Но на этом дело не заканчивается. Дальше у нас часть, которая касается так называемой автоматизации. Чем крупнее ЦОД, чем больше у него потребителей, тем сложнее решаются вопросы обслуживания и тут уже самый продвинутый, ответственный, внимательный, подготовленный администратор, даже если их будет несколько, не сможет решить эти задачи в онлайн режиме, потому что работа идет круглосуточно, 365 дней в году и нет права на ошибку. Поэтому здесь без механизмов автоматизации не обойтись.

Если есть масштабируемость, то это облако, если нет — хостинг

Следующий критерий у нас будет краеугольным. Эта такая называемая масштабируемость. В чем заключается суть этого критерия?

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

Все это должно изменяться в ЦОДах автоматически

Так вот все эти механизмы в облачных ЦОДах должны решаться и выполняться автоматически. Если потребность в вычислительных ресурсах растет, должна осуществляться процедура изменения текущей настройки. Например, сегодня у предприятия 200 почтовых ящиков, через год 400. Производительность сервера в облачном ЦОДе не должна ни в коем случае меняться, она должна пропорционально отвечать на те потребности, которые возникают со стороны внешних источников.

     В этом месте мы можем как раз провести границу, где, с одной стороны, оставим хостинг, а с другой стороны — облачные вычисления.

     Если есть масштабируемость — это реально облако, если нет масштабируемости — это просто хостинг. Дальше, мы считаем, что облачные ЦОДы, в любом случае, должны быть наделены способностью к самообслуживанию. Потому что потребители, зачастую, будут предъявлять требования в самый неожиданный момент времени, когда им это заблагорассудится. И не факт, что к этому моменту у вас будут, как у организатора ЦОДа свободные собственные ресурсы. Пускай самостоятельно эта задача решается на уровне того, кто хочет эту услугу получить. Допустим, сегодня потребитель заказал только Exchange Server, а послезавтра решил, что еще необходимо развернуть SharePoint. Он оплачивает эту услугу каким-то образом и должен получить ее не через неделю, не через 2 месяца, а сегодня и желательно прямо сейчас.

     Так вот этом случае, ему должна быть предоставлены технология, где можно эту услугу заказать и получить ее уже в качестве готового работающего результата. Естественно, без оплаты по мере использования сейчас вести разговор о каком-то коммерческом использовании того самого ЦОДа было бы бессмысленно.

Об облачной технологии выигрывают все – потребители и поставщики

Теперь давайте определимся с ролями, которые используются внутри нашего ЦОДа. Их не так много, всего 2 роли — потребитель и поставщик.

Роли внутри частного облака

     Причем, вот здесь очень важно определиться, к какому из этих элементов вы будете относить себя. На каком этапе развития вы решите, что да, действительно, строить для своего собственного предприятия огромный ЦОД не очень рентабельно, а это, на самом деле, серьезный проект и серьезные вливания. Поэтому, большинство, скажем, IT-инфраструктур перейдут в область потребления и только те из них, которые будут строить бизнес, станут поставщиками.

     Причем выигрывать будут и те, и другие.

     Вот здесь я перечислил основные факторы, основные факторы или основные элементы тех самых преимуществ, которые на этапе внедрения облачных ЦОДов получат внутри существующей инфраструктуры стороны и потребителей, и заказчиков.

Основные факторы преимуществ

     Элементы, связанные с взаимодействием поставщиков и потребителей, они, как правило, буду измеряться какими-то реальными, настоящими цифрами. Можно будет отнести к повышению скорости получения IT-ресурсов или снижению накладных расходов. Мы сейчас об этом много разговаривали, об экономии, о коэффициенте полезного действия и т.д.

     Разумеется, это будет осуществляться более эффективно, чем крупнее и масштабнее будут формироваться у нас ЦОДы. Как говориться, время покажет, насколько большие дата центры появятся здесь в Красноярске или на прилегающих территориях.

Из каких элементов и частей состоит и строится облако?

Теперь давайте два слова скажем о том, из каких элементов, частей состоит облачная технология. Причем мы здесь должны были определиться с самого начала с, так называемой, анатомией того, что будет работать внутри этих замечательных серверных коридоров, вот этих контейнерных ЦОДов или больших, крупных зданий. Отталкиваться будет от того человека, который является потребителем услуг.

     Что ему нужно в первую очередь? Ему нужен интерфейс, через который он сможет востребовать услугу. Понятное дело, что там должны присутствовать платежная система, но мы ее оставим в покое. Нам интересно как потребитель будет заказывать и получать эту услугу. Для этого мы предлагаем использовать так называемый портал самообслуживания. Он уже сейчас есть внутри наших действующих продуктов, я имею в виду Virtual Machine Manager, и его достаточно легко разворачивать. Но это сегодняшний день, мы еще дальше заглянем в завтрашний.

     Теперь смотрите, что через это портал самообслуживания можно будет сделать. Можно будет определить все характеристики действующего сервиса. Т.е. выкладывается определенная библиотека, когда начинается процедура запуска, потребитель говорит: мне нужен вот этот сервис, с конкретными параметрами, с такими-то условиями, я, потребитель подтверждаю, что меня вот этот вариант договора по обслуживанию вполне устраивает или меняю его на другой.

Формирование сервисной модели

Затем, после того как все критерии назначены, формируется, так называемая, сервисная модель. Сейчас это самый перспективный, но с другой стороны — самый сложный элемент. Потому что дать возможность создать виртуальную машину пользователю не сложно: один раз он нажал мышкой и виртуальная машина появилась. Но дело идет к тому, что пользователь будет формировать свою задачу крупнее. Он будет говорить: я хочу получить возможность развернуть SharePoint или просто хранить корпоративную информацию в общедоступном или всегда доступном месте. И вот в этот момент элементы, которые работают на уровне облачного ЦОДа, самостоятельно принимают решения:

• какие виртуальные машины поднимать;
• как их связывать между собой;
• как их настраивать;
• какие ресурсы выделять.

     В конечном итоге, формируя тут самую инфраструктуру, которая поставляет сервис конечному потребителю.

     Дальше идет следующий блок, самый крупный. Блок, который показывает, из каких же элементов состоят наши построения вот той виртуальной инфраструктуры.

• создание образа
• развертывание образа
• подключение сети
• настройка образа
• настройка сервиса
• настройка мониторинга
• настройка отчетов
• настройка бэкапа
• настройка безопасности
• мониторинг соответствия

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

Уже есть продукты и решения, которые следует внедрять в облачные ЦОДы

Что это за инструменты и как они работают? У нас есть продукты, которые сейчас следует внедрять в те облачные ЦОДы, которые строятся и которые проектируются. Я не говорю, что они самые лучшие на свете, есть много альтернативных вариантов, но тут, как говориться, я вижу, что у нас сопряженные продукты, которые могут заниматься предоставление этих услуг, функционируют уже на том уровне, который уже можно воспринимать как коммерческий уровень большого, крупного предприятия.

     Что у нас для этой задачи есть?

     У нас есть Virtual Machine Manager, Configuration Server и целая линейка продуктов Assistant центра, которые умеют, во-первых, те самые виртуальные машины создавать, настраивать их, по необходимости, обновлять и мониторить. Безусловно, это перечень очень грубый, но нет ни одного пробела, ни одного изъяна, который бы сейчас «выпадал» из законченной конфигурации.

На подходе следующие поколение продуктов управления облаком

Если заглянуть немного в будущее, то мы увидим, что на подходе у нас следующее поколение управляющих продуктов. Речь идет о Virtual Machine Manager 2012, который будет оснащаться дополнительным средством. Зачем он нужен? Он нужен для того, чтобы в зависимости от исходных условий, процедуры развертывания виртуальный машин, связки их в единое целое и предоставление их работоспособности конечному потребителю, могли бы меняться.

     Причем, разные наши поколения выглядят, разумеется, по-разному. Вот здесь я привел небольшой скриншот, который показывает, как будет выглядеть управляющий, конфигурирующий инструмент буквально через несколько месяцев. Я не уполномочен называть конкретные сроки, но ждать осталось недолго.

Управляющий инструмент

     Причем, здесь есть раздел, который контролирует появление вот тех самых базовых кирпичиков, элементов, которые связаны с непосредственно виртуальными машинами. Что делать, без них никуда не уйдешь, но это не самое главное. Самое главное — на этих виртуальных машинах базируются так называемые сервисы. Это могут быть приложения, законченные задачи, прототипы решений для конкретного потребителя или того разработанного прикладного решения, которым славится конкретно ваша компания или компания-партнер.

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

     В конце концов, если проводить декомпозицию до последнего уровня, можно увидеть, что работающий сервис, услуга, в конце концов, что покупает потребитель, базируется на виртуальных машинах, которые могут располагаться в вашем собственном ЦОДе. Часть из этих машин может располагаться в ЦОДе Microsoft или в любом другом большом учреждении, которое занимается профессиональной доставкой вот этих самых инструментов, этих самых сервисов.

     Управлять ими становится достаточно не тяжело, особенно, если учесть тот факт, что постоянно модернизуются связка взаимодействия между системами бекапирования, мониторинга, управления Не так давно, появился у нас еще один такой концептуальный элемент, изменяющий Configuration Manager. Это элемент, который оказывается, как собирается сервис из разных источников и как он подключается к конечному потребителю.

Что делать, если сервисы становятся слишком сложными?

Но что делать, если эти сервисы становятся очень сложными? Каждый их них обладает большим количеством входных элементов, уследить за ними становится, просто-напросто, невозможно. И вот тут появляется еще один элемент, который мне лично очень сильно нравиться в нашей линейке System Center, так называемый Opalis.

Сервисная модель

     Microsoft купил данный программный продукт, потому что он на рынке стал, в какой-то момент, лидером. Что он умеет делать? Opalis умеет осуществлять интерфейсную связь с абсолютно разными по технологии и по назначению продуктами, которые умеют взаимодействовать с действующими виртуальными машинами. Сейчас он называется Opalis, в следующем поколении, его название будет несколько изменено, он будет таким «оркестрантом», можно его условно назвать дирижером.

     У него интерфейс очень заметно отличается от тех самых продуктов, которые наполняют действующую модель виртуализации и действующую модель построения облачного ЦОДа. Скриншот это дело иллюстрирует

Скриншот интерфейса

     Приведу небольшой пример. У нас есть целая линейка продуктов, которая занимается каждая своей задачей. Но можно их связать воедино и заставить работать как одну команду. Например: есть Operation Manager, который способен проконтролировать показательность производительности отдельных служб, отдельных приложений или каких-то наборов этих элементов.

     В этом момент, он может сказать «оркестранту», что какие-то сервисы из своих заданных коридоров выбиваются. «Оркестрант» отдает приказания уже не Operation Manager'у, а Virtual Machine Manager'у на то, чтобы в свою очередь подготовить новый образ.

     Data Protection Manager может осуществить восстановление из заранее созданных каких-то резервных копий, либо зарезервировать то, что пока крайней мере сейчас еще находится в работоспособном состоянии.

     Очень сложные, с точки зрения логики, очень непростые решения Opalis по плечу. Но в чем тут заключается главная выгода? Один раз вы эту сложную цепочку, алгоритм настраиваете и самые удивительные, изощренные моменты, которые могут случиться с облачным сервисом, будут решаться автоматически, без прямого участия человека, без необходимости осуществлять какой-то сложный траблешутинг. Потому что это облачный ЦОД себе позволить ни в коем случае, не может.

Microsoft предлагает полный набор элементов, который позволит вам на базе выбранного проекта центра обработки данных, сделать облачный его вариант и предоставлять услуги

Microsoft уже сейчас предлагает полный набор элементов, который позволит вам на базе выбранного проекта центра обработки данных, сделать облачный его вариант и предоставлять услуги. Конечно, тут нужно сказать, что мы не в коем случае не говорим, что везде и каждому предприятию такой облачный ЦОД нужен. Но и другой альтернативы, другой альтернативной крайности не произносим. Не все будет переноситься, скажем, в те облачные ЦОДы, которые предлагаются сейчас облачными корпорациями (в силу организационных, технических, законодательных и юридических моментов). Поэтому, будет существовать симбиоз. С одной стороны локальные, частные, собственные дата центры, с другой — общедоступные облачные решения, которые по всему миру, рано или поздно, займут свое доминирующее положение.

     Дмитрий Шевелев, Exchange Configuration Server Microsoft Assistant
     Компания MicroSoft

Поделиться информацией

Вы можете послать эту статью или новость коллеге или знакомому по email со своим комментарием, пригласить обсудить ее. Просто нажмите на иконку конверта --->