Сейчас компании все больше зависят от своих информационных систем, которые должны работать непрерывно и круглосуточно, независимо от обстоятельств. Это требует использования конфигураций, в которых нет единой точки отказа. Все элементы − сеть доступа, система хранения и вычислительные ресурсы − должны дублироваться таким образом, чтобы всегда оставалась хотя бы небольшая работоспособная часть системы. Созданию именно такой, непрерывно работающей информационной системы и был посвящен семинар компании CTI под названием «Правильный резервный ЦОД для компании: лучшие практики проектирования и построения», который состоялся в самом начале февраля.
Еще совсем недавно, когда речь шла о непрерывности бизнеса, под этим подразумевали создание резервного ЦОД, в который данные передаются в режиме асинхронной репликации, а в случае аварии в нем из сохраненных резервных копий восстанавливается последнее сохраненное состояние информационной системы, которое и использует компания. Понятно, что все информационные ресурсы предприятия так резервировать не получается − слишком дорого. Поэтому приходилось выделять отдельные, наиболее критичные для функционирования предприятия системы и резервировать только их. При этом предполагалось, что резервный ЦОД работает в пассивном режиме и практически не выполняет полезной работы.
С наступлением эры виртуализации и облачных вычислений концепция резервного ЦОД несколько поменялась, поскольку появилась возможность сохранять в резерве уже не просто копии данных, а виртуальные машины целиком. Как отметил Роман Харыбин, директор департамента ИТ-инфраструктуры и ЦОД CTI, «сейчас резервный ЦОД является частью технологического процесса, обеспечивающего бесшовный переход на резервное оборудование». Фактически с повсеместным распространением технологий виртуализации появилась возможность создавать резервные ЦОД, работающие в активном режиме, или территориально разнесенные кластеры, где задачи могут автоматически перемещаться между узлами кластера в случае частичного выхода из строя оборудования. При этом оборудование обоих ЦОД постоянно находится в рабочем состоянии, а если часть его выходит из строя, просто сокращается общая вычислительная мощность. Облачные технологии дают компаниям возможность на время задействовать ресурсы сторонних операторов как минимум в части вычислительных мощностей.
Технологически процесс перемещения виртуальных машин между основным и резервным ЦОД аналогичен перемещению мобильных сотрудников в кампусной сети − об используемых для этого технологиях компании Cisco было рассказано в статье «Сетевая ткань предприятия» [http://www.connect-wit.ru/setevaya-tkan-predpriyatiya.html]. Для того чтобы виртуальная машина вне зависимости от места расположения имела всегда один и тот же IP-адрес, можно использовать связку протоколов VXLAN и LISP. Сложнее с технологиями хранения данных, которые должны обеспечивать целостное хранилище для территориально разнесенных узлов, постоянно работающих в активном режиме.
У компании Dell EMC есть решение для организации подобного распределенного хранилища под названием VPLEX, которое обеспечивает режим работы с активными узлами, разнесенными на достаточно большое расстояние друг от друга. На основе этого продукта компания CTI построила систему с резервным ЦОД для курганского оператора «Такстелеком», который обеспечивает работу службы заказа такси «Максим» и представляет набор сервисов еще нескольким компаниям, информационные системы которых также должны быть постоянно доступны. Именно для обеспечения непрерывности работы «Такстелекома» и было решено построить резервный ЦОД. Как рассказал журналу «Коннект» Александр Култашев, системный архитектор компании CTI, вначале пришлось все приложения, используемые в «Такстелекоме», перенести в виртуальную среду и только потом приступить к построению резервного ЦОД. В результате было построено решение, где оба узла кластера, разнесенных в пределах города Кургана, работают в активном режиме постоянно, а целостность системы хранения обеспечивает VPLEX. Именно такая архитектура сейчас и является наиболее эффективным способом построения резервной инфраструктуры.
Валерий Коржов
