Пока я ехал на работу и слушал новый альбом Дельфина, кто-то блокировал IP адреса Amazon и Google целыми подсетями. Роскомнадзор назвал недостоверной информацию о блокировании сайтов, не имеющих отношения к Telegram, но арендующих IP-адреса на тех же, что и мессенджер, сервисах, и создал горячую линию для противодействия распространения таких сообщений.

Поэтому я даже не догадываюсь, почему нам пришлось в течение вчерашнего дня помогать нескольким сервисам. Кого-то задело совсем немного, а кому-то пришлось мигрировать.

Если очень коротко — мы умеем быстро мигрировать из AWS. У нас совместимый API. Мигрировать клиентов из Google тоже можем. И в ближайшие недели мы готовы делать миграцию бесплатно и давать месяц на тесты в нашем облаке без договора и без гарантийного письма, просто по карточке компании. Не понравится — ничего платить не надо.

Ниже — howto для разных типов выгрузки ВМ с Амазона.

В октябре 2009-го мы всё перепроверили. Надо было строить дата-центр на 800 стоек. На основании нашей интуиции, прогнозов по рынку и американской ситуации. Вроде как звучало логично, но было страшновато.

Тогда «облачных» вычислений в России не было, как и облачных хостингов. Собственно, и само слово-то почти не использовалось на рынке. Но мы уже видели по Америке, что там подобные инсталляции пользуются спросом. У нас были за плечами большие проекты создания HPC-кластеров для авиаконструкторов на 500 узлов, и мы верили, что облако — это такой же большой вычислительный кластер.

Наша ошибка была в том, что в 2009 году никто не думал, что облака будут использоваться для чего-то, кроме распределенных вычислений. Всем нужно процессорное время, думали мы. И начали строить архитектуру так, как строили HPC-кластеры для НИИ.

Знаете, чем принципиально такой кластер отличается от современных облачных инфраструктур? Тем, что у него очень мало обращений к дискам и всё чтение более-менее последовательное. Задача ставится одна, разбивается на куски, и каждая машина делает свой кусок. На тот момент никто не брал серьезно в расчет, что профиль нагрузки на дисковую подсистему для HPC-кластеров и облака принципиально разный: в первом случае это последовательные операции чтения\записи, во втором — полный рандом. И это была не единственная проблема, с которой нам пришлось столкнуться.

Мы довольно часто помогаем бизнесу заказчика переехать в «облако». Это совершенно нормальный запрос, и большая часть крупных компаний так или иначе переносит свои мощности. Около 80% случаев приходится на перенос уже виртуализированной инфраструктуры из «домашней» серверной в дата-центр, остальные 20% — это перенос прямо с железа (включая рабочие станции пользователей) в виртуальную среду плюс вынос самого вычислительного узла в «облако».

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

Мы в КРОК запустили собственную публичную облачную платформу в России одними из первых, еще в конце 2009 года. Нам нужен был рост в геометрической прогрессии из года в год. Чтобы обеспечить подобную динамику, архитектура облачной платформы должна была быть сверхгибкой и масштабируемой, а сама платформа — хорошо управляемой. В какой-то момент мы начали упираться в архитектурные ограничения, заложенные еще на заре развития облака, а именно в подсистему хранения данных.

Одна из важнейших задач роста — обеспечение потребностей заказчиков не только в части объемов дисковой емкости, но и в части гарантированной производительности используемых дисков. Нужно было избежать взаимного влияния соседей по СХД, сделать ситуацию полностью управляемой, дать гарантии по производительности дисков в рамках SLA в пределах от 400 IOPS до 100 000 IOPS на диск.

Ко всему прочему тема с гарантированными дисками в облаке была подогрета и законом о персональных данных, вступающим в силу с 1 сентября 2015 года. Многие заказчики размещали и размещают свои ИТ-сервисы за границей, зачастую — на выделенном физическом высокопроизводительном оборудовании в ЦОДе провайдеров. Данные теперь нужно перенести на территорию России, но от высокой гарантированной производительности дисков отказываться совсем заказчикам не хочется или вовсе нельзя, а ждать поставки оборудования в РФ уже нет возможности. Облако в этом случае является, пожалуй, одним и, возможно, единственным способом успеть перенести данные в РФ и получить аналогичные технические параметры производительности, как на используемом ранее физическом оборудовании провайдера.

Любой оператор персональных данных, обрабатывающий данные не в России, может попасть под блокировку.

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

Кабель Mellanox MC2609125-005

В нашем случае Infiniband работал бы в пять раз быстрее, чем Ethernet, а стоил бы столько же. Сложность была только одна – всё это нужно было делать без прерывания облачных сервисов в ЦОДе. Ну, это примерно как пересобрать двигатель автомобиля во время движения.

В России таких проектов попросту не было. Все, кто до сих пор пытались переходить с Ethernet на Infiniband, так или иначе останавливали свою инфраструктуру на сутки-двое. У нас же в облачном «плече», которое находится в дата-центре на Волочаевской-1, около 60 крупных заказчиков (включая банки, розницу, страховые и объекты критичной инфраструктуры) на почти 500 виртуальных машинах, размещенных на примерно сотне физических серверов. Мы первые в стране получили опыт перестроения стораджевой и сетевой инфраструктуры без даунтаймов и немного гордимся этим.


Infiniband-кабель на входе в сервер

В итоге пропускная способность каналов связи между серверами «облака» выросла с 10 Гб/сек до 56 Гб/сек.

Что такое гибридное облако?
Гибридное или конвергентное облако — это сочетание минимум одного публичного облака с не менее чем одним частным облаком. Например, это связка вашего ЦОДа в офисе и облака Amazon. Виртуальные машины Amazon при этом могут быть видны в одной подсети с вашими физическими.



Для чего это делается?
Основная причина – экономия и скорость. Можно выделить себе любое количество ресурсов из публичного облака на любое время, а потом просто отключить ненужную мощность. С учётом всех деталей стоимость аренды мощностей в публичном облаке получается примерно такой же, как при покупке реального оборудования – но в первом случае все расходы операционные, а квантование не по трем годам (с заделом на амортизацию), а по секунде.

У нас тут небольшой праздник. Red Hat, Inc. (NYSE:RHT), компания, которая делает довольно известный софт с открытым исходным кодом, присвоила нам статус сертифицированного поставщика облачных услуг. Мы получили этот статус по трем причинам — во-первых, поскольку мы российский лидер в области создания ИТ-инфраструктур и системной интеграции, во-вторых, мы соответствуем требованиям Red Hat к построению публичных «облаков» (в том числе и нашего публичного «облака»), и в-третьих, потому что уже давно и тесно дружим с *nix-экосистемой.

Что это значит?

Участие в программе предоставляет КРОК возможность оказывать облачные услуги корпоративного класса с использованием ПО Red Hat. Официально, круто и хоть в госучреждениях. Это очень важно. Мы можем официально поставлять заказчикам продукт Red Hat Enterprise Linux.

Как давно мы стали красноглазиками?

С Red Hat мы сотрудничаем уже около 10 лет. Делали несколько совместных проектов для крупных российских компаний. Из самого большого — наш Виртуальный дата-центр, состоящий из двух физических ЦОДов. В нём сейчас чуть более 50 весьма крупных организаций.

К нам недавно пришел заказчик и сказал: нужно перевести работу всей компании в «облако». Желательно вчера. В общем, как и все авральные проекты — задача мечты, потому что работы много, а времени нет.

По сути, нужно было с нуля спроектировать архитектуру IT и перенести туда данные сотрудников. Со стороны заказчика — исполнительный-директор и его напарник, около 100 человек пользователей на 4 площадках, с нашей стороны — четыре небольшие рабочие группы. Одна занималась терминальным доступом, вторая — отвечала за почту. Третья занималась инфраструктурой (VPN, сетевое взаимодействие), и четвертая настройкой бэкапа.

Справились за пять календарных дней — за среду провели полный аудит ИТ-инфраструктуры компании Таврос, разработали основные архитектурные решения и выбрали технические средства для их реализации. Следующие 2 дня специалисты КРОК активно работали над развертыванием соответствующей требованиям заказчика инфраструктуры. В субботу и воскресенье допиливали мелочи и тестировали. В понедельник пользователи компании вышли на работу и ничего не заметили, но большинство ИТ-объектов уже были в нашем «облаке».

На графике – тесты производительности виртуальных машин пяти крупнейших игроков на рынке IaaS-«облаков» от cloudspectator.com и замер скорости нашего «облака» КРОК по той же методике. Разбивка по дням с 20.06.13 по 29.06.13.

Несмотря на наш приятный высокий результат, выводы данного тестирования показались нам несколько односторонними. Да и сама задача вызвала много споров среди наших коллег: ведь оценить производительность «облака» — вопрос нетривиальный. И мы решили разобраться поглубже.

«Облако» состоит, грубо говоря, из оборудования, которое позволяет этому «облаку» работать, и оборудования на котором запускаются виртуальные машины заказчиков. Производительность самих виртуалок зависит от производительности тех физических серверов, на которых они запущены. Единого стандарта нет: все на рынке предлагают совершенно абстрактные виртуальные процессоры, соответственно, совершенно разные конфигурации этих виртуралок.

Выбор облачного провайдера — сложная задача. В этом посте я расскажу, как к ней подступиться, на что обратить внимание в первую очередь, где может быть скрыт подвох, и как вообще построить общение с провайдером. Ниже — о самом сложном и комплексном сценарии развития событий, переносе всей ИТ-инфраструктуры в облако. Давайте рассмотрим перенос в «облако» критической части ИТ-инфраструктуры, недоступность которой в течение даже нескольких часов может нанести существенный ущерб бизнесу компании.

Памятка

Как отсеять хостинг провайдеров

1. Используется ли виртуализация серверов в принципе?
2. Используется ли виртуализация систем хранения данных или виртуализация сетей? Это необязательные требования, но они свидетельствуют о технологическом уровне облачного провайдера.
3. Как управлять услугами? Есть ли портал самообслуживания? Можно ли самому запускать новые серверы, управлять производительностью уже запущенных? Можно ли добавить диски, настроить внутреннюю адресацию и управлять маршрутизацией? Можно ли самому настраивать расписание резервного копирования и запускать задания по восстановлению данных? И т.д.
4. Как учитываются ресурсы? Есть ли автоматизированный биллинг (посекундный-почасовой)? Или все учитывается руками?

Площадка

1. Где расположен ЦОД: за границей или в РФ? Насколько далеко от вашего офиса и второго ЦОДа, если он есть? Задержки?
2. Кому принадлежит ЦОД? Можно ли войти посмотреть?
3. Он сертифицирован? Какие были аварии на этой площадке ранее?
4. Какие провайдеры связи присутствуют на площадке?
5. Как можно будет подключиться к «облаку»?

Услуги «облака»

1. Что такое vCPU (виртуальное ядро)? Чему оно равняется: целому физическому ядру процессора или, например, его четверти?
2. Какие используются дисковые ресурсы? Локальные или подключенные по SAN?
3. Как резервируются каналы до Интернет?
4. Что делать, если стандартного функционала «облака» не хватает? Можно ли, например, подключить к «облаку» специализированное сетевое оборудование или машины не x64 архитектуры и так далее?
5. Доступен ли гибридный режим работы? Как сделана интеграция в этом случае?
6. Есть ли сервис резервного копирования?
7. Как средства ИБ доступны в базе, какие нужно отдельно заказывать?
8. При необходимости построения HA (high availability) или DR (disaster recovery) решений возможно ли разнести части размещаемого ИТ-сервиса между двумя ЦОД? Есть ли у провайдера второе облако для построения подобных решений?

Поддержка

1. Отвечает ли поддержка 24/7, быстро и по делу, а не «мы разберёмся позже»?
2. Язык — русский и английский?
3. Как далеко можно выходить за SLA, если очень нужно? (Как правило, на Западе — ни шагу в сторону).
4. Нужно ли обращаться в поддержку за мониторингом ресурсов и баланса, или все данные доступны через портал самообслуживания?
5. Есть ли демо-режим? Насколько он отличается от «боевого» и чем конкретно?

Введение

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

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

Так давайте разберемся, кто есть кто!

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

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

Чтобы всё это работало почти «из коробки» и раза в полтора дешевле, мы сделали очень интересное SaaS-решение в своём облаке. Но для начала пройдёмся по основным моментам, облегчающим работу IT-отдела и экономящим средства.

^{EMC Avamar в ЦОД КРОК}

Вот этот здоровенный шкаф из нескольких серверов называется EMC Avamar. Он стоит у нас в дата-центре, занимается резервным копированием, и делает это очень интересно.

Что внутри шкафа?

Технологически – это блок x86-серверов, сейчас их 10 штук. Архитектура следующая: есть запасной узел и узел управления, а на остальные 8 пишутся данные. Учитывая избыточность (принцип кода Хэмминга, равномерное распределение RAIN – Redundant Array of Independent Nodes), при выходе из строя любого из узлов, данные сохраняются. Запасной узел в этот момент заменяет убитый. Итого в системе непосредственно используется только 50% каждого узла — резервный узел, узел четности и вторая половина уходит на нужды обеспечения сохранности данных. Физическая ёмкость массива 200 Тб превращается в 62,5 Тб.

Представьте задачу:

• Вы решили стартовать IT-проект, который требует большой вычислительной мощности.
• «Взлетит» он или нет, станет понятно через 3 месяца.
• Космически дорогое железо (несколько серверов по цене квартиры в Москве каждый) покупать не хочется, но при этом надо сразу стартовать так, чтобы потом не было сложностей с масштабированием до серьёзной highload-системы, то есть хочется эластичного «облака».
• В перспективе — необходимость быстро обрабатывать много данных и массу операций чтения-записи. То есть, потребуются тяжелые сервера-«молотилки», которые не могут горизонтально масштабироваться – такое в «облако» не запихнёшь.
• При этом надо создать единое сетевое пространство, как если бы «молотилки» вашего ЦОДа и сервера «облака» находились в соседних стойках, и настроить всё так, чтобы на уровне приложений не приходилось думать про физическое воплощение железа;
• Обеспечить адекватную техподдержку, которая способна закрыть все вопросы по проекту (сеть, сервера, прикладные системы) — и всё это без поиска новых администраторов себе в штат.
• До кучи — запуститься очень быстро;
• И всё это —в Москве, чтобы обеспечить минимальные лаги.

В начале этого года к нам пришел заказчик именно с такими задачами.