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

Тенденции
04.03.2015
41
10 min

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

#миграция

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

Если кратко:


Защита облачной среды принципиально ничем не отличается от традиционного дата-центра

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

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

За популярной аббревиатурой SaaS скрывается готовая к работе программа, которую нужно лишь наполнить данными. В качестве клиентской части обычно используется веб-браузер. С обратной стороны красивой медали получаем принцип «черного ящика» во всем, что касается внутреннего устройства. Работать – пожалуйста, а вот посмотреть, как там все устроено и насколько безопасно не получится. Без возможности выбора методик и технологий вся защита сводится к вере на слово и письменным соглашениям с поставщиком услуг. Понимая это, многие игроки облачного рынка раскрывают подробности построения своих систем, включая используемые механизмы защиты и наличие профильной сертификации. Чтобы немного упростить для вас выбор подходящего облака, я составил список самых важных вопросов потенциальному провайдеру. В качестве примера приложения был выбран наш собственный сервис облачной 1С: 1. Как ограничивается доступ к клиентским базам данных и серверам 1С? Важно исключить возможность чтения, копирования или изменения информации посторонними лицами и персоналом провайдера; 2. Выполняется ли шифрование клиентских данных, по какому стандарту? Зашифрованная по современным алгоритмам информация сделает кражу бессмысленной; 3. Как обеспечивается безопасность пересылаемых данных на участках: клиент-сервер 1С, сервер 1С – СУБД? Открытая передача по сети сводит на нет усилия по шифрованию хранилищ; 4. Как ограничен доступ к оборудованию, размещающему ваши приложения? Банальный доступ к консоли сервера и системам хранения позволяет обойти большинство высокоуровневых систем защиты; 5. Производится ли регулярный аудит дата-центра для проверки, что все работает как заявлено? Но не все так страшно как может показаться – давно находящиеся на рынке облачные компании прошли ни один километр рассыпанных «граблей» и нередко предлагают даже избыточный для клиента уровень защиты. Получаем удобное веб-приложение, избавляемся от головной боли с поддержкой, а заодно закручиваем гайки по части безопасности. Мечта, правда?

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

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

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

Если кратко:


IaaS практически полностью полагается на системы виртуализации вроде VMware vSphere

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

Эволюция продуктов VMware

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

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

Если кратко:


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

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

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

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

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

Если кратко:


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

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


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

подтвердил полную работоспособность

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

Oracle

Database

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

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

Если кратко:


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

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

о

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



V.Sinitskiy
Профильный эксперт