Nirvanix... Или «он улетел и не обещал вернуться»

Облачные сервисы
Nirvanix закрываетсяОблачные технологии, о которых я часто тут рассуждаю, нередко пропагандируются как панацея от всех бед. Чем они и кажутся на первый взгляд – это решение многих давно наболевших проблем связанных с самостоятельной организацией хранения и обработки данных, причем решение окончательное и бесповоротное – ни обрывы кабелей связи, ни перебои с электроэнергией вас больше не побеспокоят. Ведь теперь ваши данные располагаются в дата-центре где-то США (или Ирландии, или Германии, или где-то еще), оборудованном и защищенном от подобных неприятностей по последнему слову техники. Будь у вас хоть потоп, хоть ураган – данные (которые сейчас нередко представляют собой основу бизнеса компании) будут в безопасности.

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

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

Nirvanix была основана в 2007 году как StreamLoad. Ее основным продуктом были облачные услуги хранения данных для крупных компаний. Компания сотрудничала с тяжеловесами индустрии – IBM и Dell. Ее экспертиза в области технологий отмечалась многими изданиями. В общей сложности Nirvanix получила $70 млн долларов инвестиционных средств, в разное время и от разных инвесторов, включая $25 млн, полученных в прошлом году. Однако наблюдались проблемы с руководством и четким видением цели. За пять лет – с 2008 года – сменилось 5 CEO, причем трое из них сменились в последний год. Бизнес «в облаках» отнюдь не так прост как кажется, в этом секторе очень жесткая конкуренция. Даже успешные компании иногда закрывают неприбыльные или непрофильные сервисы. Или если не могут оптимизировать свою бизнес-модель – закрываются сами.

Когда закрывается облачный сервис или компания, это всегда доставляет клиентам массу неудобств. Приходится в срочном порядке искать куда можно перенести данные, чтобы не нарушить поток работы, хотя задержки скорее всего неизбежны так как процесс переноса в спешке редко когда проходит гладко. Nirvanix объявила что компания будет закрыта 4 октября, и дала клиентам время до 15 октября чтобы мигрировать к другим провайдерам. Также специалисты компании (а также их партнеры из IBM и Aorta Cloud) помогали клиентам сделать процесс перехода максимально гладким. Но объемы данных, которые хранили крупные клиенты достигают 10-20 петабайт, которые будет непросто даже загрузить за две недели. А ведь нужно еще и найти альтернативу, обговорить условия и заключить контракт и обновить инфраструктуру. И ведь Nirvanix можно еще рассматривать как «лучший случай», когда провайдер предупредил о надвижении катастрофы заранее и дал клиентам время на миграцию. Так бывает далеко не всегда. Как обезопасить себя на такой случай?

Очевидный ответ ясен – меньше полагаться на облачные решения и держать по крайней мере часть мощностей «у себя». Возможно, ему и стоит последовать – во всяком случае, для критически важных систем, от которых зависит функционирование бизнеса. Во-вторых, не стоит «класть все яйца в одну корзину». Распределяйте процессы и данные по нескольким провайдерам, желательно чтобы часть из них была крупными компаниями. Маловероятно чтобы гиганты вроде Amazon или Azure внезапно закроются из-за недостатка средств. Но условия, которые они предлагают иногда бывают невыгодными, поэтому их предложения лучше всего комбинировать с услугами менее известных компаний. И третий «краеугольный камень» безопасности – резервное копирование, или «бэкап».

Как известно, администраторы делятся на тех кто не делает бэкапы и тех кто уже их делает. Но мало просто сделать копию всех данных и структуры виртуальных машин, на которых они обрабатываются, надо еще чтобы от нее был толк. Больше всего пользы будет если копия будет пригодна к немедленному восстановлению. И не только на родной системе (сценарий восстановления в случае сбоя), но и на других системах – физических или виртуальных (сценарий миграции. Например с физической системы в облако. Или с одного облака в другое). Главное – выбрать адекватное решение для создания, управления и загрузки образов системы. Такое решение должно удовлетворять следующим требованиям:

  • Вся система должна подлежать восстановлению, а не только данные. Повторная установка, конфигурация и обновление ПО занимает много времени и редко когда проходит совершенно гладко.
  • Убедитесь что выбранное решение подходит для кроссплатформенной миграции. Например, с облачной платформы на физическую или наоборот. В идеальном варианте, совместимость не должна «ломаться» даже если оборудование не строго такое же. Например другие серверы, гипервизоры и т.д.
  • Решение должно поддерживать системы контроля версий и проверки наличия ошибок а также коды избыточности — чтобы убедиться что копии снимаются и восстанавливаются верно.
  • Решение не должно требовать остановки серверов для снятия копии. В идеале, после первоначального создания образа системы он должен дополняться изменениями по частям а не переписываться целиком – это гораздо быстрее и эффективнее.
  • Решение должно поддерживаться и развиваться, чтобы поддерживать новые системы и облачные платформы.

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

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn