Выбор облачного провайдера — сложная задача. В этом посте я расскажу, как к ней подступиться, на что обратить внимание в первую очередь, где может быть скрыт подвох, и как вообще построить общение с провайдером. Ниже — о самом сложном и комплексном сценарии развития событий, переносе всей ИТ-инфраструктуры в облако. Давайте рассмотрим перенос в «облако» критической части ИТ-инфраструктуры, недоступность которой в течение даже нескольких часов может нанести существенный ущерб бизнесу компании.
Памятка
Как отсеять провайдеров
- Используется ли виртуализация серверов в принципе?
- Используется ли виртуализация систем хранения данных или виртуализация сетей? Это необязательные требования, но они свидетельствуют о технологическом уровне облачного провайдера.
- Как управлять услугами? Есть ли портал самообслуживания? Можно ли самому запускать новые серверы, управлять производительностью уже запущенных? Можно ли добавить диски, настроить внутреннюю адресацию и управлять маршрутизацией? Можно ли самому настраивать расписание резервного копирования и запускать задания по восстановлению данных? И т.д.
- Как учитываются ресурсы? Есть ли автоматизированный биллинг (посекундный-почасовой)? Или все учитывается руками?
Площадка
- Где расположен ЦОД: за границей или в РФ? Насколько далеко от вашего офиса и второго ЦОДа, если он есть? Задержки?
- Кому принадлежит ЦОД? Можно ли войти посмотреть?
- Он сертифицирован? Какие были аварии на этой площадке ранее?
- Какие провайдеры связи присутствуют на площадке?
- Как можно будет подключиться к «облаку»?
Услуги «облака»
- Что такое vCPU (виртуальное ядро)? Чему оно равняется: целому физическому ядру процессора или, например, его четверти?
- Какие используются дисковые ресурсы? Локальные или подключенные по SAN?
- Как резервируются каналы до Интернет?
- Что делать, если стандартного функционала «облака» не хватает? Можно ли, например, подключить к «облаку» специализированное сетевое оборудование или машины не x64 архитектуры и так далее?
- Доступен ли гибридный режим работы? Как сделана интеграция в этом случае?
- Есть ли сервис резервного копирования?
- Как средства ИБ доступны в базе, какие нужно отдельно заказывать?
- При необходимости построения HA (high availability) или DR (disaster recovery) решений возможно ли разнести части размещаемого ИТ-сервиса между двумя ЦОД? Есть ли у провайдера второе облако для построения подобных решений?
Поддержка
- Отвечает ли поддержка 24/7, быстро и по делу, а не «мы разберёмся позже»?
- Язык — русский и английский?
- Как далеко можно выходить за SLA, если очень нужно? (Как правило, на Западе — ни шагу в сторону).
- Нужно ли обращаться в поддержку за мониторингом ресурсов и баланса, или все данные доступны через портал самообслуживания?
- Есть ли демо-режим? Насколько он отличается от «боевого» и чем конкретно?
Ремарка: многие вопросы не будут нести особой практической пользы в рамках переноса в «облако» вебсайта — не тот масштаб. Хотя сайты, конечно, бывают разные.
1. Выбор площадки
Выбор облачного провайдера начинается с физической площадки дата-центра. Если ЦОД провайдера «становится», то отключится и «облако», а значит, все работавшие в нем ИТ-системы станут недоступны. Многие спрашивают у провайдера про внутренние средства обеспечения доступности облачной платформы. Это правильно, но этого недостаточно.
Узнайте, где расположен ЦОД
В России или за границей? Это важно, поскольку некоторый тип данных по законодательству нельзя выносить за пределы РФ. Справедливо и обратное: часть данных компании стремятся спрятать в западном ЦОД, чтобы хоть отчасти защититься от проверок. Кроме того, если нужно перенести в «облако» ИТ-инфраструктуру целиком, актуален вопрос задержек. Скажем, вы решили вынести часть своих систем в публичное «облако» где-нибудь в Ирландии. Вы уверены, что имеющиеся задержки на каналах связи позволят вам комфортно работать с системами? Многих этот момент останавливает, и выбор делается в пользу локальных ЦОД.
Наш пример: у КРОК все 3 собственных дата-центра находятся в Москве и объединены единым оптическим кольцом.
Кому принадлежит ЦОД?
Также стоит обратить внимание, находится ли ЦОД в собственности у провайдера или провайдер арендует его у своего партнера. В арендованной площадке нет ничего плохого. Вполне возможно, что в компании партнера работают высококлассные специалисты, которые способны действовать быстро и слаженно в любых ситуациях. Но все-таки при аренде площадки путь вашей заявки от момента отправки до начала работы инженера компании-собственника ЦОД получается несколько дольше. В этом случае облачный провайдер выступает в качестве передаточного звена, и схема работы получается менее гибкой и оперативной.
При выборе площадки также стоит обратить внимание на возможность посетить ЦОД. Если дата-центр находится в собственности и провайдеру нечего скрывать, вас с радостью пригласят на экскурсию. Если экскурсия невозможна, то это навевает некоторые сомнения. Отказ означает, что площадка арендована и облачный провайдер не смог договориться с собственником ЦОД об экскурсии, или же что на площадке что-то не так. Конечно, могут быть и другие причины, но сомнения в надежности дата-центра все же возникают.
Все ЦОДы КРОК находятся в собственности. Экскурсии в ЦОД проводятся на периодической основе: как групповые, так и индивидуальные.
Сертифицирована ли площадка?
Лидер рынка сертификации ЦОД — компания Uptime institute. Данная компания поддерживает в актуальном состоянии перечень требований к надежности компонент ЦОД. Её требования и рекомендации построены на базе практического опыта эксплуатации дата-центров по всему миру, с учетом реальных отказов ЦОД.
Сертификация по Uptime состоит из двух этапов: сертификация проекта на бумаге и сертификация готовой площадки. Сертификация площадки занимает до трех недель. Специалисты Uptime приезжают и лично проверяют соответствие всех технических решений на площадке проектным решениям на бумаге. По итогам выдается сертификат соответствия. На текущий момент в России насчитывается 5 сертифицированных дата-центра, один из них принадлежит нам.
Существует альтернатива сертификации по Uptime institute — проверка на соответствие стандарту TIA-942. Это американский стандарт, несущий в себе рекомендации по созданию дата-центров. Минус этого стандарта — то, что он довольно давно не обновлялся и отстает от Uptime в части целого ряда требований. Также большим минусом является то, что данный стандарт носит рекомендательный характер и на соответствие ему ЦОДы не проверяют, по крайней мере, в России. Приходится верить честному слову вашего облачного провайдера.
Вообще, вопрос сертификации ЦОД — источник вечных споров. Многие говорят, что сертификация бесполезна, что они все равно не верят сертифицирующему органу (Uptime institute), как не верят и самому провайдеру услуг ЦОД. Многие, напротив, доверяют только практике работы с внешними аудиторами.
Если подойти к данному вопросу конструктивно и трезво взглянуть на вещи, то, при прочих равных, к сертифицированному ЦОД доверия больше. В случае аварии на таком объекте пострадает репутация не только провайдера, но и внешнего аудитора — а репутация Uptime дорого стоит. На несертифицированной площадке есть масса нюансов, которые очень сложно проверить, если вы не профильный специалист. Сертифицированная площадка проверена внешними профильными специалистами и содержит существенно меньше спорных технических решений.
Приведу пример небольшой, казалось бы, детали, которая может отличать сертифицированный ЦОД от несертифицированного. Она из разряда вещей, которые заказчику даже в голову не придет проверять. В ЦОДе есть система кондиционирования. Она состоит из расположенного в ЦОДе внутреннего блока (фанкойла) и установленного на крыше внешнего блока охлаждения (чиллер и градирня). Система кондиционирования зарезервирована по схеме N+1. Выход любого блока кондиционирования из строя не приводит к остановке ЦОД. Проблема кроется в том, что, чтобы заменить вышедший из строя блок кондиционирования, нужно перекрыть подвод с охлаждающей жидкостью. А если подвод всего один и не зарезервирован, то выключатся все кондиционеры, а значит, остановится ЦОД. Тут-то и «встанет» «облако» с вашими системами.
Вот еще пример: несколько лет назад в Москве был ураган. С крыши соседнего здания ветром сорвало металлический лист и бросило его на крышу ЦОД. Лист перебил подвод охлаждающей жидкости к внешнему блоку кондиционирования на крыше здания. Кто мог себе представить такой сценарий развития событий? Кто мог подумать, что что-то может случиться с системой охлаждения, размещенной на крыше и огражденной забором? В результате охлаждающая жидкость вытекла, ЦОД остановился, все системы заказчиков были отключены.
Если бы площадка была сертифицирована и построена в соответствии со стандартом Uptime institute TIER III, можно было бы переключиться на резервный подвод охлаждающей жидкости и изолировать поврежденный участок трубопровода. Поэтому, если вы выбираете облачного провайдера для переноса серьезных задач, приходится уделять внимание множеству аспектов, вплоть до уровня ЦОД. Потому что облачные услуги — это «матрешка», и ЦОД — ее сердцевина.
Кто-то может заметить, что, мол, не важно какой там у провайдера ЦОД, у нас прописан четкий SLA, в рамках него мы и работаем. И мы не хотим ездить и смотреть площадку, нам нужно «облако». Но мало кто думает о том, что, если ЦОД, а вместе с ним и все ваши системы, «встанут», то штрафы будут интересовать ваше руководство в последнюю очередь. А в первую очередь, будет скандал из-за того, что работа компании встала, и нужно срочно с этим что-то делать.
КРОК в настоящий момент владеет тремя площадками:
• Волочаевская 1 (70 стоек + облако 1) TIER 3 TIA-942
• Волочаевская 2 (110 стоек) TIER 3 TIA-942
• Компрессор (800 стоек + облако 2) TIER 3 Uptime institute
Почитать подробнее о принципах сертификации можно вот здесь.
Связь с внешним миром
У облачного провайдера всегда нужно спрашивать, как можно подключиться к ЦОД и к «облаку», в частности, извне. Какие есть варианты доступа через Интернет по умолчанию? И можно ли подключиться к «облаку» с использованием каналов точка-точка?
Если к «облаку» можно подключиться своими каналами, обязательно нужно спросить, какие провайдеры связи присутствуют в ЦОД, так как на некоторых площадках услуги связи монополизированы. Например, есть только провайдер Х и все — своих провайдеров привести нельзя.
В сети ЦОД КРОК в настоящий момент присутствуют 13 провайдеров связи, и мы готовы принять удобных вам провайдеров.
2. Облачная платформа
Процессорные ресурсы — за что платим деньги?
Мы разобрались, на что стоит обратить внимание при выборе физической площадки. Теперь перейдем к списку вопросов, которые стоит задать при выборе самой облачной платформы. Начнем с принципов выделения и продажи вычислительных ресурсов, а именно, с процессорных мощностей. На рынке существует несколько способов продажи процессорных мощностей:
- Продажа «расшаренных» ресурсов. Все, что сейчас свободно, может быть занято вашими серверами.
- Гарантированное выделение ресурсов.
Первый вариант, как правило, предлагается в красивой маркетинговой обертке. Вы можете сами выбрать нижнюю и верхнюю границы выделения вычислительных ресурсов. Нижняя граница будет выделена гарантированно, а ресурсы между нижней и верхней границами будут выделяться по требованию и оплачиваться по факту использования. Подход красивый. Но есть нюанс. Когда вам срочно понадобятся все доступные вашему виртуальному серверу ресурсы, далеко не факт, что их не используют ваши соседи по физическому серверу и что они смогут быть выделены.
Второй вариант предоставления ресурсов менее гибкий в части оплаты, зато более стабильный в части выделения ресурсов и работы ваших систем.
Использование того или иного подхода имеет ряд преимуществ и недостатков, которые могут быть выгодно использованы в той или иной ситуации. Оба подхода имеют право на жизнь.
КРОК, в частности, выделяет ресурсы гарантированно.
Что такое vCPU?
Облачные провайдеры измеряют процессорную мощность своих серверов в vCPU. Давайте разберемся, что это такое. Вот возможные варианты расчета мощности vCPU, с которыми я сталкивался:
- 0,4 – 1 ГГц частоты физического ядра процессора
- 1/3 или 1/4 физического ядра процессора
- 1 физическое ядро процессора
С этим еще как-то можно разобраться, спросив методологию расчета у провайдера. Но есть и другие подводные камни. Мощность процессорных ядер с 2007 года увеличилась в 3,5 раза. Это можно заметить по доступным типам виртуальных серверов на Амазон. В 2007 году Амазон начал предоставлять облачные услуги, и для этого было закуплено оборудование. Тогда использовались процессоры Intel Celeron. Была замерена их производительность и взята в качестве эталона. Эталон был назван ECU (Elastic compute unit). Сейчас в Амазон можно заказать виртуальные серверы, мощность физических ядер которых равняется 3,5 ECU. Отсюда можно сделать вывод о росте мощности процессорных ядер за последние 6-7 лет в 3,5 раза.
А теперь учитываем, что облачный провайдер под vCPU может подразумевать не физическое ядро, а его части, а еще может использовать старое «железо». Это означает, что vCPU у разных провайдеров может отличаться в 20-30 раз. Всегда нужно спрашивать, что такое vCPU, как vCPU соотносится с физическими ядрами и какие процессоры вообще используются.
КРОК, в частности, привязался к методологии измерения мощности процессоров Амазон.Мощность нашего vCPU равняется 3,23 ECU и соответствует мощности физического ядра процессора Intel Xeon x5650 2,6GHz.
Дисковые ресурсы
При выборе облачного провайдера стоит обратить внимание на дисковые ресурсы, которые предоставляются виртуальным машинам. В первую очередь, стоит спросить, как физически выглядит хранилище данных:
- Локальные диски на борту серверов
- Direct-attached полка с дисками
- Подключенная по SAN СХД
Первый и второй вариант чреваты потерей данных или долгой их недоступностью при выходе из строя сервера. Амазон, в частности, в качестве бонуса предоставляет заказчикам в рамках виртуальных машин дисковое пространство на локальных дисках. Выход из строя сервера чреват потерей всех данных. За дополнительную плату существует возможность аренды дополнительного дискового пространства на внешней СХД (EBS).
КРОК на этапе формирования архитектуры облачной платформы отказался от использования локальных дисков серверов для хранения данных виртуальных машин. Все диски серверов хранятся на подключенных по SAN СХД. Выход из строя физического сервера приводит к автоматическому перезапуску виртуальных серверов на выжившей части «облака».
Вторым ключевым моментом при рассмотрении дисковых ресурсов является гарантированный SLA в части IOPS, скорости чтения или записи данных. Гарантирует ли ваш провайдер определенную производительность СХД? Диски облачной платформы КРОК предоставляются без гарантированного SLA. Компания прилагает все усилия для своевременного масштабирования имеющихся СХД и добавления новых, занимается постоянным мониторингом производительности. Если заказчику нужны гарантированные IOPS рядом с «облаком», в ЦОД всегда можно разместить физическую СХД, которая удовлетворит данные требования. Наши крупные заказчики на практике так и поступают. Благо, есть 3 собственные площадки, готовые принять физическое оборудование.
Как подключиться к «облаку»?
Облачные провайдеры по умолчанию предоставляют услуги по доступу виртуальных серверов в Интернет. И делают это, естественно, по-разному.
В первую очередь, нужно спросить, зарезервировано ли данное подключение? Используются ли разные провайдеры? Как производится переключение в случае отказа одного их каналов связи?
КРОК, в частности, предоставляет для доступа из Интернет два 1Гбит канала связи от разных провайдеров, работающих в режиме активный-пассивный с автоматическим переключением между ними на уровне автономной системы.
Вторым важным вопросом является то, умеет ли провайдер шэйпить полосу пропускания каналов связи до Интернет, то есть гарантировать определенную полосу пропускания.
КРОК данную услугу не предоставляет, но постоянно проводит мониторинг утилизации каналов и своевременно старается расширять пропускную способность каналов связи.
Все наши крупные заказчики работают с удобными им телеком-провайдерами, организовывают подключение типа точка-точка. Это является более безопасным способом подключения, чем подключение через Интернет.
Что делать, если стандартного функционала «облака» не хватает?
Облачная платформа не является панацеей от всех проблем. На ней нельзя решить абсолютно все ИТ-задачи. Вот примеры, где облачная платформа вам не поможет:
- Доступные типы виртуальных серверов вам не подходят. Нужна машина с 40 физическими ядрами.
- У вас работает тяжелый сервер БД на AIX или HP-UX. Его нужно перенести в «облако». А это уже серверы не x64 архитектуры, а SPARC и EPIC. В «облаке» никак не получится разместить этот сервер на виртуальной машине.
- Провайдер не гарантирует IOPS на СХД. Нужна выделенная СХД.
- Требуется использование ГОСТ шифрования при передаче данных. Нужно установить специальные криптошлюзы.
- Требуется подключить выделенные каналы связи и управлять физическим оборудованием по переключению между каналами связи.
Примеры можно перечислять долго. Фактом остается то, что когда-нибудь вы перерастете встроенный функционал облачной платформы, если уже не сделали этого. Что вы будете делать, когда упретесь в потолок? В таком случае у провайдера нужно спросить, есть ли возможность подключения к «облаку» дополнительного физического оборудования и размещения его в ЦОД.
КРОК такие услуги предоставляет. Более того, большинство наших заказчиков арендуют у нас физическое оборудование, потребляют его в облачном режиме. Наиболее часто используется аренда сетевых маршрутизаторов для подключения выделенных каналов связи.
Интеграция с «облаком». Гибридный режим работы
Скорее всего, когда вы задумаетесь переехать в «облако», вы сделаете это не в один момент. Будет длительные переходный процесс, когда вы будете жить и на локальной площадке, и в «облаке». В некоторых компаниях этот процесс может затянуться на год, а, возможно, и не завершится никогда.
В этом случае у провайдера важно спросить о механизмах интеграции вашей локальной ИТ-инфраструктуры с «облаком».
Если рассмотреть использование публичного «облака», то по умолчанию управление сетевыми настройками на стороне «облака» практически отсутствует:
- Вы не можете управлять внутренней адресацией. Если бы могли — случился бы коллапс.
- Вы не можете управлять маршрутизацией.
- Если рассматривать большинство российских провайдеров, то сети внутри «облака» построены на VLAN’ах. Как правило, 1 заказчик = 1 VLAN. Все машины живут в одной сети. Далеко не у всех можно создавать дополнительные VLAN.
Управление сетями внутри «облака» далеко от того уровня гибкости и удобства, который доступен на собственной площадке. Про средства по сетевой интеграции и вовсе стоит забыть. От силы существует возможность построения VPN-туннеля между площадками.
К счастью, существуют технические решения по реализации такого же удобного механизма работы с сетями в «облаке», как и на локальной площадке.
КРОК использует программное обеспечение по виртуализации сетей, про которое было рассказано в предыдущем посте. Данное ПО позволяет заказчику самостоятельно, через портал самообслуживания, управлять:
- Внутренней адресацией сетей «облака»
- Создавать необходимое количество дополнительных сетей
- Управлять доступом между ними посредством Firewall
- Настраивать статическую или динамическую маршрутизацию
- Делать выгрузку конфигураций для локального физического сетевого оборудования для настройки VPN
Таким образом, данный функционал позволяет настроить внутреннюю адресацию в «облаке» удобным вам способом, вплоть до построения горизонтальных L2-сетей между площадками. Вы можете самостоятельно настроить VPN и прописать маршруты. Фактически, вы можете управлять сетевыми настройками в «облаке» так же, как вы это делали бы у себя на площадке. «Облако» фактически становится логическим продолжением вашей локальной инфраструктуры на площадке заказчика. ИТ-системы могут совершенно прозрачно работать друг с другом, несмотря на то, что будут располагаться в физически разных местах.
Если вы предполагаете плотную интеграцию вынесенной в «облако» части систем с локальными системами, нужно будет обязательно поинтересоваться у провайдера о возможностях по управлению сетями.
Резервное копирование данных
Резервное копирование данных является одним из базовых сервисов облачной платформы. Но многие про него забывают. У провайдера нужно для начала спросить, имеется ли такая услуга в принципе. Если все-таки имеется, то можно задать дополнительные вопросы. Используется коммерческий продукт или Opensource? Если используется свободное ПО, то сразу стоит закладывать риски того, что поддержкой этого решения занимается сам провайдер, а не вендор.
Отсюда вытекает второй риск. Вендор комплектует свое ПО по резервному копированию всеми необходимыми агентами для консистентного бэкапа прикладного ПО. Вряд ли у вас получится забэкапить SAP с использованием Opensource решения по резервному копированию. У провайдера всегда нужно спросить список совместимости для данного решения по резервному копированию.
Важно уточнить у провайдера, на чем хранятся копии, на дисках или на ленте. Лента является более дешевым носителем информации, но риск не восстановиться гораздо выше. Более того, работа с лентой происходит медленнее, чем с дисковым носителем. Если информация хранится на дисках, а вам в качестве дополнительного сервиса нужно периодически переписывать копии на отторгаемые носители, то у провайдера нужно поинтересоваться о такой возможности.
Ну и наконец, важным моментом является тип предоставления услуги. Как ей можно управлять? Есть ли портал самообслуживания? Можно ли самому управлять расписанием по резервному копированию, бэкапить и ресторить данные без привлечения провайдера?
КРОК построил свое решение по резервному копированию на базе программно-аппаратного комплекса ЕМС Avamar. Информация хранится на дисках в дедуплицированном виде. Управление услугой производится посредством полнофункционального портала самообслуживания.
Информационная безопасность
Данный вопрос является наиболее часто обсуждаемым и наиболее страшным для облачных провайдеров.Так на что же стоит обратить внимание? Помимо вопросов о средствах обеспечения доступности (резервирование оборудования и каналов связи, раздельное хранение данных, RAID, бэкапы) стоит спросить про состав встроенных средств по управлению доступом, а также про перечень дополнительных сервисов ИБ.
В части встроенных средств стоит спросить про парольную защиту Windows-машин про защиты Linux-машин посредством ключей. Вы создали новую машину, каким образом защищается доступ к ней? Она сразу становится доступна всему Интернету по внешнему IP-адресу со стандартным паролем?
Также стоит спросить и про управление сетевым доступом. Есть ли возможность управлять встроенным Firewall, если он вообще, конечно, есть?
В части дополнительных сервисов нужно поинтересоваться у провайдера возможностью покупки услуг по защите от (D)DoS, а также систем по обнаружению и предотвращению вторжений (IDS, IPS) и по аренде антивируса и антиспама.
Построение disaster recovery или high availability решений
Существует некоторая вероятность того, что ваши задачи станут настолько критичными, что потребуется их резервировать между ЦОД, стоить кластеры, настраивать репликацию между СХД. Готов ли ваш провайдер к такому повороту событий? Или придется привлекать второго провайдера?
Привлечение второго провайдера чревато размыванием ответственности и работой с двумя службами технической поддержки, возможно, в рамках разных SLA. Это может негативно сказаться на работе вашей ИТ-инфраструктуры.
КРОК на данный момент имеет 2 собственные облачные платформы, расположенные в разных ЦОД (Волочаевская-1 и Компрессор). Управление обеими платформами производится через единый портал самообслуживания. Это позволяет строить высокодоступные распределенные решения. Ну, или как минимум, хранить бэкапы на удаленной площадке относительно основных данных.
При этом даже отсутствует необходимость подписания дополнительного договора. Для заказчика процесс работы с двумя облачными платформами совершенно прозрачен.
Заключение
Даже задав провайдеру-претенденту весь перечень вопросов и получив на них ответы, не стоит на этом останавливаться. Нужно попросить предоставить демо-доступ, чтобы на практике убедиться во всем услышанном. В конце концов, протестировать производительность серверов, СХД и сети на своих задачах. Тестирование будет самым ярким индикатором того, подходит вам конкретный провайдер или нет. Ручается он за свои слова, соответствуют ли реальности его обещания?
Но и на этом не все. К сожалению, многие особенности работы с облачной платформой нельзя прочувствовать на этапе тестирования. Некоторые сюрпризы будут неизбежно всплывать в процессе продолжительной эксплуатации сервиса. Эти сюрпризы могут оказаться как некритичными, так и сильно заметными, после которых будет поставлена под сомнение возможность последующей работы с данным провайдером.
В конце общения с провайдером всегда нужно обговаривать вопрос переезда к другому поставщику услуг. Нужно узнать возможности по забору данных, по конвертации виртуальных машин в нужный формат и т.д.
Автор: MBerezin
