Чем облако пугает бизнес? Топ 5 опасений относительно перспектив миграции в облако

#1 «Мы не уверены в конфиденциальности наших данных в облаке»

Если кратко:

• Защита облачной среды принципиально ничем не отличается от традиционного дата-центра, подходы одни и те же. Зачастую возможно даже использование привычных инструментов обеспечения безопасности;
• При выборе SaaS решения стоит помнить, что для вас это будет «черный ящик». Значит, вы сможете влиять на безопасность информации в очень ограниченных пределах - стоит выяснить у провайдера, какие меры по защите данных принимает он. Как правило, серьезные поставщики облачных услуг сообщают такую информацию. Шпаргалку по «каверзным вопросам» вы сможете найти далее в этом разделе;
• Если необходим больший контроль над данными, то имеет смысл рассмотреть IaaS – инфраструктурное облако. Подобная схема облачной организации позволит внедрить любые механизмы защиты и получить конфиденциальность в четком соответствии с вашими корпоративными стандартами.

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

Методы защиты корпоративных данных от посторонних глаз можно разделить на правовые (договора и соглашения) и технические (права доступа, шифрование и прочее). Правовые меры в какой-то степени подстрахуют от последствий раскрытия информации, но никак не предотвратят сам инцидент. В то же время, с технической стороны возможности пользователя облачной системы могут быть заметно ограничены. Чтобы разобраться с вопросом, рассмотрим подробнее две самые популярные модели: SaaS и IaaS.

Программа без программистов

За популярной аббревиатурой SaaS скрывается готовая к работе программа, которую нужно лишь наполнить данными. В качестве клиентской части обычно используется веб-браузер. С обратной стороны красивой медали получаем принцип «черного ящика» во всем, что касается внутреннего устройства. Работать – пожалуйста, а вот посмотреть, как там все устроено и насколько безопасно не получится.

Без возможности выбора методик и технологий вся защита сводится к вере на слово и письменным соглашениям с поставщиком услуг. Понимая это, многие игроки облачного рынка раскрывают подробности построения своих систем, включая используемые механизмы защиты и наличие профильной сертификации. Чтобы немного упростить для вас выбор подходящего облака, я составил список самых важных вопросов потенциальному провайдеру. В качестве примера приложения был выбран наш собственный сервис облачной 1С:

Но не все так страшно как может показаться – давно находящиеся на рынке облачные компании прошли ни один километр рассыпанных «граблей» и нередко предлагают даже избыточный для клиента уровень защиты. Получаем удобное веб-приложение, избавляемся от головной боли с поддержкой, а заодно закручиваем гайки по части безопасности. Мечта, правда?

Серверы без администраторов

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

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

1. Сетевой доступ к виртуальным серверам клиента обычно ограничен извне брандмауэрами с функцией защиты от разнообразных атак, включая популярные в последнее время DDoS;
2. Виртуальная среда клиента изолируется на уровне управляющего ПО (виртуальные дата-центры, vApp и прочее), исключая доступ к данным «соседей». Применяются политики разграничения прав доступа для сотрудников дата-центра и специалистов заказчика;
3. Информация на дисках может быть зашифрована как на уровне провайдера (хранилище виртуальных дисков), так и со стороны клиента (логические диски, пользовательские папки).

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

#2 «Эти новомодные технологии еще сырые и не годятся для реальной работы»

Если кратко

• Облачная инфраструктура обычно строится на проверенных технологиях и продуктах. К примеру, IaaS практически полностью полагается на системы виртуализации вроде VMware vSphere. Подобные продукты совершенствовались более десяти лет и по праву считаются надежным решением для повышения надежности и гибкости серверной инфраструктуры;
• В «облаках приложений» (SaaS) не редко используются специальные версии привычных технологий (MS Exchange, 1C, MS Office и прочие), поэтому подвоха ждать тоже не стоит. Конечно, есть эксклюзивные разработки специально для облачной модели – но тут риск не более чем у любого нового «традиционного» ПО;

Когда-то операционные системы от Microsoft служили объектом насмешек по определению, независимо от реалий. Теперь же их можно встретить в большинстве банкоматов, на кассах и в карточном процессинге – и ни у кого не возникает сомнений в зрелости Windows. Точно так же сейчас обстоят дела с облачными решениями, которые у кого-то еще ассоциируются с молодыми и малопригодными в работе технологиями.

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

На рисунке представлена краткая эволюция продуктов VMware, от первых систем виртуализации до комплексных решений для корпораций и коммерческих дата-центров. В основе всех решений лежит технология с более чем 10-летней историей – гипервизор ESXI, зарекомендовавший себя как наиболее производительный и надежный фундамент для любого приложения.

Еще одним аргументом против виртуализации традиционно считается более низкая скорость работы виртуального сервера в сравнении с физическим. Даже если не принимать во внимание зачастую несущественную разницу, в облачной среде этот аргумент в принципе не имеет смысла. Все дело в том, что любые издержки от более низкого КПД виртуализованных серверов несет провайдер. Пользователь услуги просто приобретает желаемый объем мегабайт и гигагерц, и реальные расходы провайдера его уже не касаются.

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

#3 «А если дело не пойдет, разве мы сможем отказаться от IaaS/SaaS или сменить поставщика?»

Если кратко:

• Практически любое облако позволяет его покинуть, мигрировав как обратно на старые серверы, так и к другому провайдеру;
• Чтобы процесс вынужденной миграции был осуществим, стоит заранее проверить возможность выгрузки данных у вашего нового облачного провайдера (экспорт информации в популярный формат для переноса, архивы с виртуальными машинами в OVF). В таком случае вся миграция сводится к копированию файлов и перенастройке доступа клиентов;
• Сразу после переезда в облако не торопитесь выбрасывать старое оборудования и очищать диски – первое время устаревшая площадка может поработать в качестве резервного ЦОД. Можно настроить репликацию виртуальных машин или данных, подстраховавшись от любых неожиданностей;
• При выборе провайдера не забывайте интересоваться репутацией компании, сроком ее присутствия на рынке и наличием «портфолио».

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

Действительно, а что если облачный провайдер не оправдает надежд? В сущности, есть два пути покинуть существующее облако:

1. Перенести данные обратно на старые серверы и наладить работу так же, как было до переезда;
2. Мигрировать информацию к другому провайдеру, если облако в целом устраивает и вопросы есть лишь к поставщику услуги.

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

1. Если использовалась модель SaaS, то приложение провайдера Х может быть не совместимо по формату данных с детищем компании Y. В лучшем случае удастся экспортировать информацию в какой-то третий формат, поддерживаемый обеими системами. Но практика показывает, что такие случаи обычно заканчиваются многими часами ручного труда;
2. 2. Компания Х может не предоставлять возможности выгрузки или переноса размещенных у нее виртуальных серверов или данных. Звучит несколько фантастически, но лучше проверить; 3. В случае с IaaS при выгрузке у вас будет набор файлов виртуальных серверов. Хорошо, если миграция происходила из старого дата-центра с аналогичной системой виртуализации. Хуже когда компания переезжала с физических систем или другой платформы;

Хорошая новость в том, что эти сложности можно преодолеть путем некоторых контрмер:

1. Для SaaS важно заранее предусмотреть возможную миграцию в будущем и убедиться в поддержке новым приложением некоего стандартного формата переноса данных. Более удобным вариантом будет специальный импорт данных конкурирующими системами. Зачастую, производители такого ПО предлагают довольно ограниченные возможности экспорта, но охотно помогают с переносом чужих данных на собственные мощности;
2. Облачная инфраструктура несколько проще при миграции, так как все ведущие производители систем виртуализации поддерживают стандартный формат виртуальной машины OVF. Единственное, в чем стоит дополнительно убедиться, так это в возможности выгрузить виртуальные серверы в такой формат;
3. Для IaaS также полезно отработать процедуру обратной миграции V2P (virtual to physical) если ранее вы использовали традиционный дата-центр. Средства подобной миграции зависят от операционной системы и ее приложений, но как вариант может применяться схема «резервная копия виртуального сервера – восстановление на физическом оборудовании»;
4. На некоторое время после переезда в IaaS полезно обеспечить параллельную работу старой и новой площадки средствами приложений или самой системы виртуализации. Например, для VMware vSphere может быть полезен Site Recovery Manager - с его помощью возможен перенос всей инфраструктуры на старую площадку. 

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

#4 «Наше приложение слишком большое и важное для вашего облака»

Если кратко:

• Облачные технологии обычно строятся на системах виртуализации, которые с успехом выполняют многие высоконагруженные сервисы (SAP HANA, к примеру). Если у приложения заявлена возможность запуска на виртуальных серверах, то с облаком тоже никаких сложностей быть не должно;
• Если вендор вашего приложения не заявляет совместимость с виртуальной средой, то имеет смысл проверить наличие новой версии. Сейчас все больше производителей ПО стремятся предложить клиентам работу с более совершенным виртуальным дата-центром;
• Облачная инфраструктура способна предложить очень высокий уровень надежности благодаря технологиям высокой доступности виртуальных систем, наличию профессионально оборудованного дата-центра и специально подготовленного персонала;

Согласно исследованиям агентства Gartner, одним из популярных мифов об облачных вычислениях является их неприменимость для бизнес-критичных приложений. В таких случаях мне сразу хочется вспомнить про крупные ERP системы вроде SAP, но всему свое время. Давайте вспомним, чем критичное приложение отличается от не критичного с точки зрения техники.

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

1. Отсутствие формальной поддержки виртуальной среды вендором приложения. Не всегда под этим скрываются реальные технические сложности, что не мешает производителю отказать вам в технической поддержке по причине несовместимости конфигурации;
2. Критичное приложение может быть установлено на «большом» сервере (более 16 процессоров, несколько ТБ памяти) не столько из-за реальной потребности в такой производительности, сколько из-за уровня надежности машины. В серверах подобного класса значительно больше дублирующих компонентов повышенной надежности от всевозможных аппаратных сбоев;
3. Зачастую подобное приложение предъявляет жесткие требования к дисковой системе, что заставляет использовать специфичное оборудование. Система хранения с необходимым интерфейсом или возможностями может просто отсутствовать у облачного провайдера. Несмотря на наличие быстрых дисковых систем в IaaS, приложение может быть жестко привязано к типу подключения (InfiniBand, FC);

Как водится, что-то из ограничений можно обойти, а с чем-то придется мириться.

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

• Функции «бесшовной» миграции между физическими хостами (vMotion, Storage vMotion);
• Службы репликации виртуальных машин, включая межсайтовые (vSphere Replication);
• Возможности постоянной синхронизации процессорных инструкций и оперативной памяти (vSphere Fault Tolerance). При выходе из строя хоста виртуализации эта технология мгновенно активирует самые важные приложения на страхующем сервере. При этом ни одного «пинга» потеряно не будет!
• Возможности замены всех критичных узлов виртуального сервера без его остановки (добавить процессор, изменить объем памяти, или установить еще один сетевой адаптер).

Сложнее обстоят дела с жесткими требованиями к системе хранения. В качестве примера, можно привести обязательное подключение сервера критичного приложения напрямую к системе хранения, без прослойки виртуализации (pRDM в среде VMware). Это возможно сделать и для виртуальной системы, но не избежать потерь в гибкости виртуальной среды: будет затруднен перенос виртуальной машины, недоступна технология мгновенных снимков и пр. Универсальной рекомендацией тут будет ознакомиться с документацией к новым версиям вашего приложения, ведь «драконовские» требования могли банально устареть.

В качестве реального примера работы «больших» приложений в виртуальной и облачной среде можно привести продукт SAP HANA. Компания SAP давно зарекомендовала себя как ведущий мировой производитель систем управления предприятием и поддержки продаж. Продукт HANA представляет собой высокопроизводительную СУБД для действительно требовательных приложений, с необычным размещением данных. Вся пользовательская информация БД хранится в оперативной памяти сервера и доступна для запроса с минимальными издержками. Производитель подтвердил полную работоспособность этой платформы в виртуальной среде VMware.

Аналогичную позицию в отношении виртуальных систем занимает и Oracle. Например, поддерживаются сценарии виртуализации одной из самых популярных БД для высоконагруженных систем - Oracle Database.

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

#5 «А стоят ли преимущества усилий на переезд?»

Если кратко:

• Если вы ранее уже переносили приложения и данные на виртуальные серверы, то большинство сложностей с переездом на IaaS позади. Так как облако строится на виртуальных системах, то миграция сводится к копированию файлов виртуальных машин и перенастройке доступа клиентов;
• Новые возможности управления облачными ресурсами позволят серьезно повысить уровень обслуживания со стороны вашего ИТ-подразделения, а также сэкономят много времени на рутинных операциях обслуживания серверов.

Если вы уже переносили приложения с физических серверов в виртуальную среду, то наверняка сталкивались с множеством подводных камней. Вендоры систем виртуализации давно поддерживают специальные инструменты миграции P2V (physical to virtual), но даже эта мера не всегда сглаживает углы. Любую миграцию сложно назвать простым занятием, со всем этим множеством «граблей» и неочевидных ситуаций. Зная об этом и помня свой предыдущий опыт, ИТ-специалисты опасаются переезда в облачную среду.

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

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

Например, VMware vCloud Director позволит автоматизировать развертывание набора серверов для приложения с распределенной архитектурой. Поверьте, ваши разработчики и инженеры оценят возможность быстро и просто получить в свое распоряжение типовой полигон. Аналогично можно упростить управление всеми этими серверами и, наконец, красиво реализовать правильный порядок их запуска, остановки и обновления.