Книга 3 решения по проектированию, построению и организации эксплуатации телекоммуникационных и вычислительных мощностей цод егисз (основной, резервной и тестовой площадок)
Скачать 1.18 Mb.
|
1.3.4.Размещение ИС ФЦОД ЕГИСЗМатериал раздела предоставляется по отдельному запросу 1.3.5.Обеспечение катастрофоустойчивости ФЦОД ЕГИСЗПод катастрофоустойчивостью следует понимать способность к восстановлению работы приложений и данных за минимально короткий период времени после глобального катаклизма. Предполагается, что под катастрофами понимается не только пожар, наводнение или землетрясение, но также и возможные непредвиденные сбои в работе коммунальных служб, повреждение работоспособности ЦОД по любым причинам, включая обрыв телекоммуникационных линий, и умышленную внешнюю или внутреннюю диверсию. Для обеспечения катастрофоустойчивости информационных систем ЕГИСЗ, предлагается архитектура с территориальным разнесением площадок, на которых размещается ФЦОД ЕГИСЗ, см. Рисунок .  Рисунок – Обобщенная архитектура взаимодействия компонентов ФЦОД ЕГИСЗ Предлагается следующий состав площадок: Основная площадка №1; Основная площадка №2; Резервная площадка; Тестовая площадка. Тестовая площадка используется для обеспечения работ по разработке и тестированию компонентов ЕГИСЗ и может быть организована на базе любой из площадок в виде выделенного дополнительного набора вычислительных ресурсов и дополнительных систем хранения данных. Площадки №1 и №2 должны взаимно резервировать друг друга в реальном режиме времени. Для этого данные обеих площадок должны реплицироваться в синхронном режиме, а компоненты одной площадки должны иметь возможность использовать ресурсы компонентов другой площадки. При выборе расстояния между площадками с синхронно реплицируемыми данными, с одной стороны, необходимо их разносить на максимальное расстояние друг от друга, для обеспечения минимизации влияния катастрофы одной территории на другую, с другой стороны, необходимо учитывать потерю производительности функционирования сервисов при удалении площадок друг от друга. Наличие синхронизированных данных на основных площадках №1 и №2 позволит обеспечить минимальное время восстановления предоставляемого сервиса. Для обеспечения синхронной репликации между площадками №1 и №2 и исключения существенной деградации производительности прикладных систем необходимо обеспечить круговую задержку сигнала между площадками на уровне единиц миллисекунд. С учетом скорости распространения света в оптическом волокне задержка сигнала составляет порядка 5 мксек/км, также учитывая дополнительные сервисные задержки, общая задержка сигнала составляет порядка 20 мксек/км. Соответственно на расстоянии 50 км, можно ожидать получение круговой задержки сигнала порядка 2 миллисекунд, а для 100 км - 4 мсек. Снижение производительности систем при увеличении расстояния указывается рядом производителей оборудования и программного обеспечения в исследовательских отчетах. В качестве примера, можно рассмотреть количество операций ввода/вывода при разнесении серверов и системы хранения данных. В одном из исследований, зафиксировано снижение количества операций ввода/вывода на 37% для расстояния 100 км (2200 iops для 100 км и 3500 iops для расстояния 400 метров), и на 14% на расстоянии 50км (3000 iops для 50 км и 3500 iops для расстояния 400 метров), см. рисунок «Figure3-20» по ссылке: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/HA_Clusters/HAGeoC_3.html. Таким образом, расстояние между площадками №1 и №2 необходимо обеспечить в пределах 50-100км друг от друга. При таком территориальном разнесении площадок №1 и №2 можно обеспечить отказоустойчивость прикладных сервисов от локальных аварий на уровне одного здания или группы зданий. Однако, при сбоях более глобального характера, таких как землетрясение или глобальные перебои электроснабжения региона в котором находятся обе площадки №1 и №2 для возможности продолжения функционирования сервисов ЕГИСЗ требуется создать резервную площадку, отнесенную на более значительное расстояние от основных площадок. Это расстояние определяется несколькими факторами: для минимизации попадания в зону с высокой вероятностью землетрясений, расположение основной и резервной площадок должно быть на различных тектонических платформах и должно обеспечиваться значительное удаление основной и резервной площадок от места «перекрытия» с другими тектоническими платформами, см. карту на Рисунок ; необходимо предусматривать подключение основной и резервной площадок к сетям электроснабжения, входящие в разные региональные энергосистемы, или входящие в разные объединения энергосистем, см. таблицу «Таблица ».  Рисунок - Тектоническая карта Российской Федерации Таблица - Соотношение территорий федеральных округов, регионов и энергосистем (источник Системный оператор Единой энергетической системы» (ОАО «СО ЕЭС») - http://www.so-cdu.ru/index.php?id=fops)
Катастрофоустойчивая архитектура предполагает защиту от незапланированных простоев информационных сервисов во время и после катастрофы. В данной архитектуре, должно обеспечиваться следующее: резервирование сетевых связей между площадками ФЦОД ЕГИСЗ; прикладные компоненты ЕГИСЗ должны функционировать: либо на основных площадках; либо на одной резервной площадке. При этом необходимо обеспечить следующую функциональность: взаимная репликация данных между площадками №1 и №2 обеспечивается в синхронном режиме; прикладные компоненты ЕГИСЗ могут функционировать на обеих площадках №1 и №2 одновременно; при частичной неисправности или полном выходе из строя одной из площадок №1 или №2, прикладные компоненты ЕГИСЗ должны функционировать с перерывом в работе, стремящимся к нулю; распределение клиентского доступа к основным площадкам должно осуществляться с учетом обеспечения минимального времени отклика от любой из основных площадок; репликация данных с основных площадок на резервную площадку обеспечивается с задержкой и возможно в асинхронном режиме; восстановление после катастрофы (failover) - репликация данных с основных площадок на резервную и запуск информационных сервисов на новом месте; возврат в исходное состояние (failback) - репликация данных с резервной площадки на основные, обычно после устранения последствий катастрофы или в целях тестирования; возможность запуска программных компонентов информационных сервисов на той или иной площадке, как в тестовом, так и в промышленном режиме (например, на время проведения профилактических работ); переключение конечных пользователей к той или иной площадке ФЦОД ЕГИСЗ, в зависимости от текущей доступности ИС на необходимой площадке. Все данные информационных сервисов должны находиться в консистентном состоянии на всех площадках и могут быть использованы сразу после запуска соответствующих виртуальных машин. Время восстановления на резервной площадке при операции failover (без учета организационных издержек) определяется временем запуска виртуальных машин. Т.о. учитывая следующие исходные данные: среднее время запуска виртуальной машины (VM) - 3 мин; усредненный количественный состав информационной системы - 24 VM (например ФЭР); все VM ИС кластеризованы, что означает необходимость запуска только половины VM; время восстановления одного информационного сервиса, при последовательном запуске (например, сперва должны стартовать серверы БД, далее уже после их вхождения в устойчивое состояние, производится пуск серверов приложений) 12 виртуальных машин составит 36 минут = 24*3/2. При конфигурировании последовательности запуска машин, в зависимости от конфигурации информационной системы, можно сократить количество последовательных запусков и ряд компонентов запускать параллельно. В таком случае, общее время старта информационной системы может быть сокращено в несколько раз, предположительно до 10 минут. С учетом организационных и непредвиденных издержек восстановление одной информационной системы, при глобальной катастрофе и выходу из строя всех основных площадок ФЦОД ЕГИСЗ может укладываться в RTO, равное 30 минутам. Общее время восстановления всех информационных систем при глобальной катастрофе и выходу из строя всех основных площадок ФЦОД ЕГИСЗ зависит от налаженности процессов восстановления и может достигать нескольких часов. Для сокращения этого времени необходимо создание и регулярное тестирование плана восстановления для случая катастрофы (Disaster Recovery Plan). Требуемый уровень доступности сервисов, размещаемых в Федеральном ЦОД 99,9% , т.е. 8,76 часов простоя в год, реально достижим даже при отсутствии Основной Площадки №2. Предполагая, что состав прикладных компонентов ЕГИСЗ равен 10, то даже при последовательном восстановлении каждого компонента общее время перевода функционирования сервисов с площадки на площадку оценочно составит 5 часов = 10*30мин. Если учесть, что каждый прикладной компонент ЕГИСЗ размещается в отдельном виртуальном ЦОД, т.е. являются независимыми и изолированными друг от друга, то все операции восстановления (с учетом успешно проведенного, заранее предварительного тестирования), могут проводиться параллельно. В таком случае, RTO для всех компонентов может быть снижено до уровня 30—60 минут. Наличие Основной Площадки №2, позволит дополнительно снизить RTO, при условии распределения функционирования прикладных компонентов ЕГИСЗ между площадками. 1.3.6. Организации репликации данных между основными и резервной площадкамиДля переноса (репликации) данных с основных площадок ФЦОД ЕГИСЗ на резервную и обратно, необходимо использовать программно-аппаратный комплекс средств репликации, см. Рисунок .  Рисунок - Архитектура репликации данных между площадками ФЦОД ЕГИСЗ Программно-аппаратный комплекс средств репликации желательно использовать в режиме out-of-band (управление “вне” потока данных), позволяющее освободить от нагрузки на репликацию, вычислительные мощности, как серверов, так и систем хранения данных. Основные требования к средствам репликации: обеспечение асинхронной доставки данных; гетерогенность – возможность использования широкого спектра массивов/серверов/операционных систем/приложений; обеспечение консистентности данных на разных площадках - согласованность данных друг с другом, целостность данных, а также их внутренняя непротиворечивость; поддержание синхронизированных по времени копий нескольких томов одного приложения (консистентная группа); возможность удаленного восстановления независимо от расстояния; обеспечение дедупликации данных для устранения передачи повторяющихся данных на удаленную площадку, экономя пропускную способность канала. в качестве сети передачи данных должна использоваться возможность передачи по IP сети (Layer 3); используемые средства репликации должны содержать средства интеграции с гипервизорами, обеспечивающими виртуализацию ресурсов, что позволит обеспечить комплексное взаимоувязанное решение по репликации виртуальных машин; масштабируемое, с высоконадежной архитектурой решение. Для обеспечения синхронной репликации данных между основными площадками №1 и №2 возможны варианты на основе различных технологий: либо с использованием программных менеджеров томов (Volume Manager), устанавливаемых в операционную систему каждого виртуального сервера; либо с использованием программно-аппаратных средств репликации, совмещающих возможность осуществления и синхронной и асинхронной репликации, в том числе средства обеспечения виртуализации систем хранения данных. При выборе средств синхронной репликации следует отдавать предпочтение, внешним, по отношению к серверам, средствам репликации, для исключения необходимости настройки программных менеджеров на уровне каждой виртуальной машины. 1.3.7.Средства резервного копирования и восстановления данных ФЦОД ЕГИСЗФЦОД ЕГИСЗ будет размещен в инфраструктуре облачной среды, где уже должна быть развернута система резервного копирования и восстановления (СРКВ). СРКВ должна являться гибкой, расширяемой и масштабируемой системой, позволяющей задействовать имеющие и добавленные мощности с учетом требований информационных систем ФЦОД ЕГИСЗ. Сервис резервного копирования и восстановления должен поддерживать работу в территориально-распределенной структуре и обеспечивать: создание локальной резервной копии на каждой основной площадке и дополнительной копии на резервной площадке; отказоустойчивость заданий копирования и восстановления с помощью использования множественных путей для передачи данных; балансировку нагрузки на серверы системы резервного копирования при их неравномерной загруженности; возобновление операций копирования при перемещении виртуальных машин на резервную площадку; развертывание управляющего сервера системы резервного копирования в отказоустойчивой конфигурации с помощью стандартных средств кластеризации; катастрофоустойчивость системы резервного копирования с возможностью восстановления работоспособности управляющего сервера СРКВ на удаленной площадке при его потере на основной площадке; работу с дисковыми устройствами хранения данных; возможность резервного копирования на уровне образов виртуальных машин, используя интегрированное взаимодействие с гипервизорами; гранулярного восстановления отдельных файлов и директорий; возможность резервного копирования и гранулярного восстановления объектов СУБД; использование специализированных агентов на выделенных серверах для минимизации влияния процессов резервного копирования на продуктивные виртуальные машины; обеспечивать возможность масштабирования по производительности и объемам резервируемых данных; обеспечивать выполнение операций создания резервных копий и дедупликации данных в автоматическом режиме на основе расписаний резервного копирования, задаваемых администратором; обеспечивать возможность автоматизированного восстановления; обеспечивать возможность делегирование восстановления объектов администраторам информационных систем. Количество виртуальных машин подлежащих резервированию должно соответствовать общему количеству виртуальных машин. Система резервного копирования и восстановления данных в территориально-распределенной структуреРезервное копирование на уровне образов виртуальных машин должно использовать интегрированное взаимодействие с гипервизорами с возможностью оптимизации с использованием технологий инкрементального копирования на уровне блоков (механизм отслеживания измененных блоков), исключением удаленных блоков из резервных копий образов виртуальных машин, содержимого swap-файлов. Такая конфигурация представляет собой резервное копирование виртуальных машин offhost-типа на основе снимков (Snapshot) виртуальных машин. Требуется реализация функции гранулярного восстановления данных на файловом уровне отдельных файлов и директорий, объектов. Система резервного копирования может быть построена по трехуровневой модели: клиент – сервер копирования данных – сервер управления. Клиентами СРКВ будут являться серверы, на которых развернуты информационные системы ЕГИСЗ, в частности: СУБД; серверы приложений. В состав СРКВ входят следующие аппаратные компоненты: сервер резервного копирования; ресурсы дискового массива, для целей резервного копирования. В состав СРКВ будут входить следующие программные компоненты: сервер резервного копирования; агенты резервного копирования; агенты интеграции с приложениями.  Рисунок - Схема организации СРКВ СРКВ должна иметь отработанные процедуры восстановления, для чего в автоматизированном режиме на специальных серверах должны проводиться с определенной периодичностью процедуры проверки восстановления данных из сделанных ранее копий. Действующий состав информационных сервисов ЕГИСЗ должен определять требования к системе резервного копирования, в части объема резервируемых данных. Отдельные функциональные требования к СРКВ следующие: реализация резервного копирования данных баз данных, настроек операционных систем и приложений, виртуальных машин; регулируемое количество хранимых резервных копий. Время восстановления информационных систем, при использовании СРКВRecovery time actual (RTA) — реальное время восстановление складывается из совокупности факторов, таких как: время реакции системы мониторинга, инженеров линии поддержки, программно-аппаратной конфигурации. Время восстановления определяется следующими основными параметрами: производительностью сети хранения данных, производительностью СХД. Оборудование сети хранения данных и СХД (как основной, так и резервной площадок) должны обеспечивать скорость передачи данных не ниже 8Гбит/с. Производительность СХД определяется множеством параметров, включая наиболее медленные компоненты – жесткие диски. Предполагая, что для целей резервного копирования будут взяты медленные жесткие диски NL SAS с производительностью 0,768Гбайт/с (6,1 Гбит/с) можно рассчитать время восстановления 21 минута=(1Тбайт*8/6,1Гбит/с)/3600с. При восстановлении одной информационной системы в рамках одной площадки, (например, с объемом данных 10ТБ), учитывая организационные издержки, можно предположить время восстановления не более 4 часов. Необходимо отметить, что хотя время восстановления с помощью СРКВ превышает время восстановления, достижимое при использовании механизмов переключения прикладного сервиса с одной площадки на другую, однако данный механизм позволяет восстановить данные даже после логического сбоя, например, вследствие ошибочных действий пользователей ЕГИСЗ. Резервное копирование виртуальной инфраструктурыДля резервного копирования и восстановления групп виртуальных машин должны использоваться специальные программные средства. Наряду с восстановлением виртуальных машин целиком, СРКВ должна предоставлять возможность гранулярного восстановления данных виртуальных серверов на уровне файлов и директорий для ОС MS Windows и Linux. Для создания копии виртуальной машины возможно использование механизмов мгновенного снимка диска виртуальной машины. Снимок представляет из себя диск виртуального сервера, который монтируется сервером с установленным агентом с целью копирования на заданные типы устройств резервного копирования. Все необходимые для восстановления метаданные, включая время создания копии и имена виртуальных серверов должны храниться на серверах, через которые должен проходить трафик резервного копирования (для многих коммерческих систем, такие серверы именуются - Media Agent) и в индексном каталоге СРКВ. Поддержка функциональности гипервизоров, должно осуществляться отслеживанием измененных блоков и организацией карты измененных блоков данных, что может позволить уменьшить продолжительность фазы чтения данных подлежащих резервному копированию и сократить объем данных резервного копирования. Данные ИС могут резервироваться двумя способами, исходя из архитектуры системы и типов приложений использующихся в нем: резервное копирование виртуальных машин. На данном уровне происходит копирование всех данных ОС, настроек, контейнеров виртуальных машин и т.п.; резервное копирование базы данных для целостного сохранения копии данных используется встроенное в СУБД ПО. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие:
 | Понятие электронной медицинской карты (эмк) и интегрированной электронной медицинской карты (Иэмк) 5 | | Понятие электронной медицинской карты (эмк) и интегрированной электронной медицинской карты (Иэмк) 5 |
 | Субподрядчик: определяется в процессе аукциона на выполнение работ по проектированию и монтажу лвс | | Инструкция предназначена для работников жилищно-коммунального хозяйства, научных, учебных, проектных, природоохранных организаций... |
| Инструкция предназначена для работников жилищно-коммунального хозяйства, научных, учебных, проектных, природоохранных организаций... | | Сведения предоставляются на основании Решения Межрегиональной инспекции фнс россии по цод №5277 от 23 октября 2009 года о предоставлении... |
| Понятие судебного решения и требования к нему. Вступление решения в законную силу 31 | | «Правила эксплуатации гражданских аэродромов, гидроаэродромов, вертодромов и посадочных площадок» |
| Правила устройства и безопасной эксплуатации подъемников (вышек)* устанавливают требования к проектированию, устройству, изготовлению,... | | Работ публикуется впервые. В работах прослеживается основное направление исследований создание нетрадиционных высокопараллельных... |