Наверное, уже все слышали, что в соответствии с вступившим в силу Федеральным законом от 21 июля 2014 г. № 242-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях" необходимо организовать хранение и обработку персональных данных в России. Тема, конечно же, коснулась почти всех зарубежных финансовых организаций, представленных у нас в стране. Колесо завертелось и волею судьбы мы выиграли на исполнение проект одного зарубежного банка по созданию ИТ-инфраструктуры под миграцию его информационных систем (ИС) в Россию. Сорри, контракт включает NDA, поэтому назвать банк не можем. Но можем рассказать, как все это мы реализовали, какое решение предложили, архитектуру, СПД, какие вендоры – в общем, весь наш опыт передаем ниже.

Немного подробнее о предпосылках задачи

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

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

Итак, с одной стороны для выполнения закона ФЗ-242 перед зарубежными компаниями встал вопрос переноса информационных систем, обрабатывающих персональные данные, на территорию РФ. В тоже время, на территории этих компаний работают бизнес-критичные ИС, которые содержат максимально важные для заказчика данные и обеспечивают работу бизнес-критичных процессов. Такие системы клиенты старались держать за границей ради консолидации и обеспечения защиты от пресловутых рисков в России, таких как рейдерские захваты и нежданные проверки различных органов или «слив» конфиденциальной информации конкурентам.

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

Далее перейдем к конкретной задаче, которую нам пришлось решить для зарубежного банка ввиду вступившего в силу ФЗ.

Задача банка

Итак, задачу, которую поставил перед нами банк, можно сформулировать так — создать необходимую ИТ-инфраструктуру для работы переносимых бизнес-критичных информационных систем с заданными показателями производительности и надежности.

Требования

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

По показателям:

RPO (Recovery point objective – сколько данных будет потеряно при аварийном восстановлении) – в нашем случае заказчик хотел получить восстановлении RPO = 0 в случае локальных сбоев, и RPO стремящееся к 0 в случае катастрофы в основном ЦОД. Иными словами, в случае локального сбоя не должно быть потери данных, а в случае глобального сбоя потеря данных должна быть минимальна.

RTO (Recovery time objective – время, за которое возможно восстановить ИТ-систему) — заказчик хотел время восстановление <= 1 часа в случае самого худшего локального сбоя и RTO <= 2 часов в случае катастрофы в основном ЦОД.

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

2. Достаточная производительность информационных систем на новом оборудовании не хуже, чем до переезда. Это должно было обеспечиваться со всех точек зрения – например, как вычислительных ресурсов, так и с точки зрения СХД.

Часть ИТ-систем заказчика работала на платформе IBM Power. Для этой платформы мы собрали статистику использования ресурсов с учетом средней и пиковой нагрузки. При сайзинге важно знать, насколько могут отклоняться показатели от среднего значения в течение дня, недели или года, чтобы ИТ-системы сохраняли работоспособность даже в худшем случае максимальной нагрузки в случае пиковых нагрузок, например, при закрытии квартала.

Можно также посчитать производительность в неких условных синтетических показателях, таких как количество IOPS с определенным блоком и соотношением чтения к записи. Эти метрики мы учитывали при сайзинге нового оборудования.

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

3. Эффективное вложение денег и эффективное использование оборудования. Заказчик ставил задачу с точки зрения бизнеса обеспечить выполнение требований №1 и №2 в минимальный бюджет. При этом в отличие от многих проектов российских заказчиков учитывалась не только стоимость первоначальных вложений – CAPEX, но и OPEX — стоимость поддержки и сопровождения решения в течение 5 лет.

Решение

ЦОДы и резервирование

Когда заказчик говорит о непрерывности в случае как локальных, так и глобальных сбоев, необходим резервный ЦОД. Если что-то в основном ЦОДе сгорит, то через некоторое время системы смогут возобновить работу, развернувшись на новом месте.

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

Соответственно, требовался либо «теплый» резерв, либо «горячий». Заказчики, как нормальные иностранцы, предъявляли требования, чтобы между ЦОДами было не менее 100 км для исключения всякого влияния (веерного отключения ЛЭП или, например, глобальной катастрофы в Москве). С экономической точки зрения синхронная репликация была не целесообразна, так как потребовались бы существенные инвестиции в канал между ЦОД, трафик по которому должен был быть зашифрован. С технической точки зрения задержки на таком расстоянии между ЦОД уже могли начать влиять на скорость работы информационных систем, поэтому был выбран вариант с асинхронной репликацией между ЦОД.

«Железо» и ПО под RISC-системы

Для информационных систем, работающих на архитектуре RISC, были выбраны сервера E870 на платформе IBM Power. Они предназначены для размещения бизнес-критичных нагрузок с самым высоким уровнем доступности и обладают полным набором функционала RAS (Reliability, Availability and Serviceability).

Эти серверы виртуализуются на аппаратном уровне с помощью IBM PowerVM, и в них создаются разделы виртуальных серверов (LPAR). В LPAR выделяют процессорные ядра для выполнения нагрузки. Их можно выделить в LPAR как монопольно – без переподписки ресурсов, так и в общий пул для совместного использования пулом виртуальных серверов. Можно ограничить предельное потребление ресурсов из общего пула виртуальных серверов сверху в пиковых режимах. Архитектура подсистем Power представлена на рисунке ниже.

Рис. Архитектура подсистем IBM Power

Любые серверы, даже такие надежные как IBM Power E870, где практически все задублировано, могут отказать. Поэтому для защиты от сбоя сервера используется программное обеспечение высокой доступности (HA). В нашем случае наиболее хорошо подходило кластерное ПО – Veritas Infoscale. Это ПО имеет существенное преимущество перед решениями с простым HA. Оно позволяет сделать одновременно локальный кластер (HA) как между серверами на одной площадке, так и между площадками (DR). В итоге заказчик будет застрахован от локального сбоя и сбоя всего основного ЦОДа.

Veritas Infoscale позволяет организовать 3-х стороннюю репликацию данных. Это когда данные дублируются в 2-ух местах на одной площадке и одновременно идет непрерывная IP репликация в РЦОД. Технически, возможно было бы сделать это и более простыми и дешевыми средствами, но существенный плюс ПО Veritas Infoscale в том, что в случае сбоя одной из реплик на локальной площадке не потребуется вручную перенастраивать репликацию. В результате данные клиента постоянно остаются под защитой, даже в случае локального сбоя.

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

Рис. Структурная схема созданной целевой архитектуры катастрофоустойчивого решения

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

Однако в серверах High End IBM Power (в том числе E870) можно максимально эффективно использовать активации процессоров и памяти, объединяя их в общий Enterprise Pool. Активации из пула можно использовать на любом из серверов пула. Для оптимизации стоимости решения на резервных серверах можно закупить меньше активаций по сравнению с основным, что и было нами сделано. В тоже время в случае сбоя на этих серверах можно будет использовать весь объем активаций пула.

«Железо» и ПО под архитектуру x86 банка

Для информационных систем, работающих на x86/VMware, было выбрано решение на блейд-серверах HP Proliant Bl460 Gen9 и ПО виртуализации VMware vSphere Enterprise Plus. Архитектура подсистемы серверной виртуализации показана на рисунке ниже.

Рис. Архитектура подсистемы серверной виртуализации

Для защиты от сбоя одного хоста использовалась кластерная технология VMware High Availability, которая позволяет рестартовать виртуальные машины сбойного хоста на других.

Образы и данные виртуальных машин хранятся на нескольких СХД. Бизнес-критичные данные дублируются на как минимум 2-мя СХД и презентуются хостам через виртуализатор СХД EMC VPLEX. Это позволяет исключить одну СХД как точку отказа. Сбои на 2-ух контроллерной СХД обычно редки, но они бывают. Может отказать батарейка кэш-памяти одного контроллера, что приведет к выключению кэша и существенной деградации производительности.

Данные передаются через сеть хранения данных по Fibre Channel с использованием 2-ух фабрик для резервирования от логических и физических сбоев. Фабрики между ОЦОД и РЦОД не объединяются из-за существенного расстояния между ними (более 600 км).

Для защиты от катастрофы в ОЦОД применено апробированное решение на базе VMware SRM и репликации с помощью выделенных устройств — EMC RecoverPoint. Они дублируют все операции вывода из ОЦОД в РЦОД в асинхронном режиме. В случае достаточной пропускной способности канала такая репликация дает RPO близкое к 0. Устройства RecoverPoint позволяют сжимать трафик между площадками и передавать только уникальные блоки, что снижает требования к каналу.

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

Сейчас многие банки задумываются или уже создают свой резервный ЦОД (или РЦОД). Однако этого может быть недостаточно, поскольку дата-центры в Москве могут иметь общую инфраструктуру. Оба дата-центра могут питаться через одну подстанцию, может произойти веерное отключение подстанций, оптические трасы к ЦОД могут подходить через одну точку…

Преимущество созданного нами комплекса решений EMC VPLEX + EMC RecoverPoint + VMware vSphere HA позволяет обеспечить защиту от сбоев на базе 3-ех ЦОД – двух близко расположенных и одного расположенного относительно далеко на случай катастрофы. Это позволяет банку получить синхронную репликацию с нулевой потерей данных в случае сбоя в одном ЦОД, а также защиту от глобальных катастроф.

В нашем проекте мы реализовали 2-е площадки – ОЦОД и РЦОД. Но в ОЦОД мы разместили 2-а комплекта оборудования. Получается, как 2-а ЦОД в одном. В обычном случае полезная нагрузка работает на обоих, но в случае отказа продуктивная нагрузка может работать и на одном комплекте. Это позволяет обеспечить самые высокие требования по доступности информационных систем в различных случаях сбоев.

Решение в части СПД

Итак, в части СПД нам необходимо было построить катастрофоустойчивое решение на три ЦОДа для обеспечения максимальной доступности ИС.

Заказчик к началу проекта уже имел два ЦОДа с сетевым оборудованием Cisco. Использовались коммутаторы Nexus, включая FEX, а также DMVPN с филиальной сетью. Естественно, это определило сохранение вендора при модернизации сети.

Архитектура

В целом архитектура в основном ЦОДе у нас вышла классическая:

• в качестве ядра Nexus 5672;
• в качестве коммутаторов доступа Nexus 2000 серии;
• для портов управления использовался Catalyst 2960X.

В WAN и Internet сегментах:

• пара маршрутизаторов ASR 1001X для подключения к операторам с L3VPN облаками;
• пара маршрутизаторов ASR 1001X для организации функций DMVPN и QOS;
• маршрутизаторы ISR4431 для подключения к Интернет;
• файерволлы PaloAlto для связи с офисами;
• файерволлы Chackpoint для связи с Интернет.

В резервном ЦОДе все аналогично за исключением переиспользуемых моделей Nexus 5548UP и ASR1001. Также нужно упомянуть про Out of band (OOB) интернет-каналы в каждый ЦОД с отдельными межсетевыми экранами. Схемы там самые классические, поэтому здесь их даже не прилагаем.

Связь с сетью Интернет

Со связью с Интернетом получилось более интересное решение. У заказчика в наличии была только одна сеть PI /24. При этом было необходимо:

• анонсировать PI сеть только из основного ЦОД (ОЦОД) пока он жив (как в Интернет, так и вовнутрь СПД);
• PI сеть должна переезжать в РЦОД при отказе всего ЦОД;
• PI сеть должна переезжать при двойных отказах одного типа оборудования в ОЦОД: ядро, Интернет-каналы, маршрутизаторы, файерволлы или WAN коммутаторы;
• PI сеть не должна переезжать при двойных отказах аналогичного оборудования в резервном ЦОДе;
• PI сеть не должна переезжать при двойных отказах каналов между ЦОД;
• доступность Интернет-каналов должна проверяться по нескольким подсетям из Интернет (например, 8.8.8.0/24).

Таким образом, доступность ОЦОД из РЦОД нужно было проверять через внутреннюю сеть и через Интернет одновременно. Проверка доступности Интернета у нас осуществляется с помощью Cisco IP SLA. Естественно, в ОЦОД и РЦОД используется условное анонсирование PI сети по BGP в сторону операторов, а также условное анонсирование в локальную сеть в ОЦОД.

Ниже приведена логическая схема:

Обнаруженные интересные детали с оборудованием Nexus

Как уже отмечалось, в проекте были использованы коммутаторы Nexus 5672UP. При их использовании обнаружено 2 бага, которые Cisco планирует переделать в фичи :)

Первое — медные breakout DAC кабели 40G на 4x10G. В нашем случае эти кабели были совместимы со всем оборудованием, но они периодически флаппали. Понятно, что даунтайм небольшой, но это происходило достаточно часто. Сами кабели изображены ниже:

В итоге после долгих тестов, медь заменили оптикой, и все проблемы исчезли. Оптические кабели, на которые заменили ниже:

Вроде бы Cisco пока планирует исправлять документацию – исключать данные кабели из списка совместимых. Так что лучше не экономить и покупать только оптические DAC кабели.
Про Nexus 7000 серии есть вот такой документ. Ключевая фраза «Passive copper optic cables are not supported on the non-EDC ports». Получается, что вся пассивная QSFP медь может некорректно работать и на Nexus 5600 серии.

Второе — Microsoft SLB. Все помнят режим, при котором на сети настраиваются статические ARP и MAC записи без IGMP. Причем, если не указать статические MAC записи, то пакеты будут флудиться по всему VLAN. Так вот, теперь последнее утверждение не будет верным для Nexus 5672UP. Чтобы данные передавались, нужно будет в обязательном порядке указывать статические mac записи. Под этот кейс Cisco тоже планирует изменить документацию.

Предложенное решение в части СПД – связь между ЦОД (DCI) и офисов (WAN)

При модернизации связь между Main ЦОД и DR ЦОД, а также между ЦОД и филиалами должна быть переведена на шифрование с ГОСТ алгоритмами. Между ОЦОД и РЦОД достаточно было L3 связности.

Сетевое оборудование Cisco ничего не должно знать о криптошлюзах, поэтому поверх шифрованных туннелей мы построили GRE/mGRE. Таким образом, остаются работать протокол динамической маршрутизации EIGRP.

Криптошлюзы в обоих ЦОД должны строить VPN-туннель между собой, а также до филиалов. В качестве криптошлюзов были выбраны S-Terra. Одной из причин стала очень похожая настройка на Cisco. В принципе такой вариант работы с S-Terra описан на их сайте, поэтому ничего сложного обычно не возникает.

Время восстановления сети после сбоев

Что касается времени восстановления при отказах для сети, то, как известно, оно зависит от используемых технологий и протоколов, а также схемы резервирования оборудования и каналов.

Все сетевое оборудование и каналы резервировались по схеме 1+1.Для резервирования на канальном уровне использовались популярные вещи LAСP и VPC с субсекундным временем восстановления после отказа.

В данном проекте у заказчика уже использовались протоколы EIGRP в локальной сети, между филиалами и BGP для взаимодействия с операторами. В случае локальной сети EIGRP делает конвергенцию с субсекундными таймерами при обнаружении отказа. По сравнению с OSPF протокол EIGRP для таких результатов гораздо проще настраивать. Нужно только выполнять одно из двух условий для резервного маршрута – equal cost multi path (ECMP) или feasible successor. В OSPF для этого придется тюнить много таймеров.

В целом, в локальной сети практически невозможны неявные отказы оборудования или кабелей. Поэтому общее время конвергенции будет меньше 1 секунды. Если говорить про WAN сегмент и всю распределенную сеть (связь между филиалами и ЦОД), то максимальное время восстановления при отказах составит 5 секунд.

В случае связи с интернетом, время восстановления получается, конечно, больше – до 1 минуты. У заказчика уже была своя PI сеть. В рамках модернизации в BGP стали принимать всю таблицу маршрутизации. Собственно это нужно, чтобы защититься от некоторых отказов внутри интернет провайдеров. Так, мы исключаем ситуацию, когда BGP peer виден, но дальше со связью все плохо.

Чтобы добиться восстановления интернета за 1 минуту при отказе оборудования или канала необходимо договариваться с операторами об уменьшении keepalive и hold таймеров. На практике у нас показывают хорошие результаты keepalive в 3 секунды и hold в 10 секунд. Флапов при таких значениях никогда не происходит, хотя при 2-х и 7 секунд соответственно — уже наблюдаются. Правда, не все операторы готовы по умолчанию поддерживать такие значения, но договориться можно. :)

На этом все. Заказчик доволен. Если есть вопросы по решению, будем рады ответить.

Авторы материала:

Артем Бурдин, инженер-проектировщик отдела вычислительных систем центра компетенций по вычислительным комплексам компании «Техносерв»

Михаил Шеронкин, руководитель направления корпоративных сетей центра компетенций по сетевым технологиям компании «Техносерв»

https://habrahabr.ru/post/332982/