Почему DR в «облаке»?
Начнем с простого – что нужно заказчику от Disaster Recovery решения? В первую очередь, чтобы оно работало. Это значит, что в случае аварии на основной площадке бизнес-процессы компании восстановятся в полном (или неполном, но заранее установленном) объеме. На этой стадии до облачных вычислений очень далеко, но если «копнуть» поглубже, становится понятно, что «облако» – оптимальное решение. Во-первых, создание идеального решения с помощью традиционных технологий может оказаться слишком дорогим. Заказчик хочет оптимизировать расходы – и это нормально. С другой стороны, нет ничего хуже, чем экономить на безопасности и непрерывности процессов. Компромисс – арендовать инфраструктуру, вместо того, чтобы ее покупать.
Второй момент: системы заказчика не статичны, а значит, решение, обеспечивающее их аварийное восстановление, тоже должно меняться, причем в том же темпе. Возникает потребность в гибком управлении арендованной инфраструктурой, чтобы заказчик мог самостоятельно синхронизировать ее с основной площадкой и оперативно вносить нужные изменения.
Как только возникает необходимость аренды ИТ с возможностью гибкого управления – появляется «облако».
Последовательность процесса восстановления
Есть множество вариантов реализации Disaster Recovery as a Service, и самый продвинутый из них – решение, которое работает в онлайн-режиме. Под заказчика резервируется весь спектр вычислительных ресурсов, на удаленной площадке хранится копия данных, которая актуальна в любой момент. И «облако» в таких проектах вообще не является проблемой: оно уже рассматривается как рабочий, надежный инструмент. Сложности заключаются в другом…
Какие сложности? Как их преодолеть?
1. Проблемные каналы связи
Иногда проблемой становятся инфраструктурные элементы, не имеющие отношения ни к провайдеру, ни к заказчику. Например, идеально настроенное, полностью синхронное решение может «ломаться» дважды в день просто потому, что рвется канал связи. Есть даже специальный термин для такого явления: “split-brain” – “разделенный мозг”, системы не видят друг-друга и не понимают, что делать дальше.
В решении этой проблемы (да и других тоже) нам очень помогает то, что КРОК – интегратор. Это предполагает индивидуальный подход к заказчикам, в отличие, например, от подхода некоторых зарубежных облачных гигантов. При этом стратегия публичных облачных операторов тоже правильная и, как показывает опыт, успешная. Это просто разные подходы: как автобус и Мерседес, которые никак не конфликтуют друг с другом за пассажира 🙂 В «облаке» публичного провайдера все стандартно, он дает заказчику канал публичного Интернета, поверх которого можно запустить что угодно, но для Disaster Recovery этого недостаточно – слишком медленно и далеко. Что делаем мы? Мы придумали, как безопасным образом просверлить «дырку» для канала связи в нашем «облаке». И либо прокладываем волоконно-оптический канал между площадкой заказчика и нами, либо предоставляем выделенный канал связи по договоренности с оператором, а лучше (на всякий случай) – с двумя.
Консоль управления условиями SLA
2. Наличие у заказчика систем, которые «не дружат» с «облаком»
Некоторые системы технически невозможно перенести в «облако». Например, тяжелая база данных, работающая только на UNIX-системе, не может жить на гибкой виртуальной платформе. Чтобы обеспечить ее восстановление, необходимо подключать к «облаку» аппаратные ресурсы. И мы умеем это делать: опять же, потому что КРОК – интегратор.
3. Конфликт ПО и инструментов виртуализации
Часто приходится сталкиваться с несовместимостью программного обеспечения и инструментов виртуализации. Причем, на самом деле, технической проблемы в том, чтобы использовать софт одного вендора на виртуализаторе другого, нет: в облачной системе они, скорее всего, даже «не видят» друг-друга. Но зачастую ограничения вводятся производителями ПО, чтобы продвигать собственные решения.
Для того, чтобы решить эту проблему, мы нашли действительно классный инструмент – Double Take. Дополнительным плюсом при выборе было то, что компания, производящая это решение, выпускает также Disaster Recovery продукты для серверов System i от IBM, кластеризовать которые необычайно сложно. Double Take – решение для репликации программных кластеров с помощью сети Интернет. Это значит, что кластеры могут находиться как угодно далеко. Кроме того, этой технологии неважна платформа, на которой создано решение, а значит, становится возможным реплицировать и кластеризовать системы, работающие в двух разных виртуальных средах.
Ну и, конечно, не стоит забывать, что даже если прикладным системам заказчика нужен конкретный инструмент виртуализации, а у нас его нет – при необходимости он появится, и очень быстро. Такие случаи уже были: помимо нашего стандартного виртуализатора Red Hat, появились решения от Oracle и VMware – ими уже успешно пользуются заказчики.
Вывод
Подводя итог: «облако» – это гибко, удобно и надежно. Сейчас это уже не вызывает сомнений. Сомнения могут вызывать сложности, связанные с переходом в мир, где все стандартно, виртуализовано, «облачно». Но и в этом мире возможен индивидуальный подход к заказчику и комплексное решение стоящих перед ним задач – наш пример это доказывает. А мой опыт также показывает, что перевод ИТ-систем в «облако» высвобождает немало денег и (что не менее ценно) времени под важные дела 🙂
Руслан Заединов http://i-business.ru/