Разработка и реализация эффективных стратегий аварийного восстановления с помощью технологии Citrix. Часть 1. План

Введение

За последние пять лет мы стали свидетелями поистине катастрофических событий. Угон 11 сентября и ураган Катрина причинили ужасные разрушения как людям, так и местам. Помимо этого, они также оказали ужасное влияние на организации и их способность выживать во времена кризиса. Целые центры обработки данных были уничтожены. Людям было приказано эвакуироваться, и они не могли оставаться, чтобы справиться с тем, что осталось. Инфраструктуре Нью-Йорка и Нового Орлеана был нанесен огромный ущерб. Внезапно ИТ-менеджеры столкнулись с критическими кадровыми решениями и осознанием того, что у них нет возможности снова запустить свои организации. Аварийное восстановление стало главной силой в лексиконе ИТ-терминала.

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

Определите свои уровни критичности

Первый шаг — определить уровень критичности. В худшем случае ваш дата-центр просто сгорел/взорвался/затоплен. Как бы то ни было, оно недоступно. Что вы за организация? Вы представляете финансовое учреждение, где каждая минута простоя стоит денег? У вас есть производственная линия, зависящая от ваших приложений, или грузоотправители, которым нужен постоянный доступ к инвентарным номерам? Все это критические компоненты. Ваша организация должна понимать уровень критичности каждого компонента. Электронная почта имеет решающее значение для вашего успеха, или она может подождать 24 часа? Что важнее для вашей текущей деятельности, внешние веб-серверы или ваша система расчета заработной платы? Это решения, которые можете принять только вы.

Многие организации придумают класс для критичности бизнеса. Например, в моей нынешней компании мы определяем 5 уровней BC, где 5 — самый низкий приоритет, а 1 — самый высокий. К каждому уровню BC привязан свой уровень ответа, и любому приложению или компоненту инфраструктуры, введенному в среду, присваивается BC как часть процесса. Например, БК, равный 5, означает, что мы как организация можем прожить без этой детали до месяца. БК, равный 1, означает, что без него мы не можем прожить более 4 часов. Когда у вас есть структура для ваших уровней BC, становится легче думать об отдельных компонентах и требованиях для каждого из них.

Оцените свое окружение

Теперь, когда у вас есть отправная точка, начните оценку среды и назначьте соответствующие уровни BC. Некоторые будут очевидны. Мощность, вероятно, BC1. Без него много чего не сделаешь. Сеть вполне может быть BC1. В конце концов, если ваши серверы не могут обмениваться данными, это может стать препятствием. Как насчет вашей среды электронной почты? Является ли это столь же важным компонентом? Смогли бы вы прожить 4 часа, 8 часов, 24 часа без электронной почты? Каждый компонент должен быть оценен сам по себе и как часть головоломки инфраструктуры. Например, если сервер приложений имеет BC1, но использует базу данных Oracle, вы не можете использовать базу данных как BC3. Это может быть очень сложная сеть, особенно с большими и сложными средами, в которых есть несколько двух- или трехуровневых приложений для восстановления.

Одна хитрость состоит в том, чтобы разделить вашу инфраструктуру на более крупные сегменты. Каждый сегмент — это все приложения/серверы/все, что необходимо для взаимодействия друг с другом. Вы назначаете BC для всего фрагмента, а затем определяете план восстановления, чтобы они поднимались в порядке критичности в этом сегменте. В этом случае все BC1 не созданы равными! Например, в вашем сегменте бухгалтерского учета может быть 6 разных систем, каждая из которых имеет общий BC1. Но в этом сегменте и при разработке процедур восстановления вы знаете, что база данных Oracle должна быть установлена в первую очередь. Затем ваш сервер Peoplesoft или SAP, или как вы хотите определить этот приоритет. Это дает вам хороший способ убедиться, что каждая часть восстанавливается в правильно определенный период времени, а также дает вам возможность понять взаимосвязь между каждой частью и порядок, в котором они должны быть приоритетными, даже в пределах их собственной BC.

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

Выбор сайта аварийного восстановления

Выбор вашего сайта DR может быть дорогим предложением. Для небольших организаций второго сайта может вообще не быть. Многие предпочтут попытаться восстановить на основном объекте или решат, что, если он исчезнет, они все равно мало что смогут сделать. Некоторые организации, которые достаточно велики, чтобы использовать несколько центров обработки данных, будут использовать их в качестве отказоустойчивых площадок в случае аварийного восстановления. Третий вариант — заплатить одной из крупных организаций по хранению данных, такой как Iron Mountain или Sungard, за предоставление вам места на их объекте для восстановления вашей среды в случае аварийного восстановления. Часто эти компании находятся в безопасных местах в других крупных мегаполисах и будут взимать плату в зависимости от ваших требований к пространству и хранению. Это может быть привлекательным вариантом, если у вас нет ресурсов для собственного объекта, но часто в таких местах есть ограничения по времени и пространству. Вы можете столкнуться с трудностями при настройке среды в соответствии с вашими спецификациями, и если вы решите использовать собственное оборудование для арендованных площадей, это означает, что вы получите небольшую поддержку со стороны менеджеров объекта.

Для тех площадок, которые достаточно велики, чтобы уже иметь дополнительные центры обработки данных, планирование аварийного восстановления означает рассмотрение того, что дополнительная нагрузка будет означать для вашего центра обработки данных. Емкость на каждом объекте должна иметь достаточные накладные расходы для ожидаемого всплеска в ситуации аварийного восстановления. Очевидно, что ваша инфраструктура должна поддерживать переключение сети на новый центр обработки данных, клиенты должны будут перенаправляться и т. д.; К счастью, с хорошей инфраструктурой DNS эта задача стала намного проще, чем раньше. Последнее соображение касается вашего механизма восстановления.

Как вы восстанавливаете?

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

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

Вывод

Это просто краткий обзор того, как справиться с аварийным восстановлением в вашей организации. В следующей части этой статьи я представлю конкретный сценарий для среды Citrix и расскажу, как применяются все эти шаги аварийного восстановления. Аварийное восстановление — сложный, дорогой и часто упускаемый из виду компонент стабильной инфраструктуры. В наши дни вы действительно не можете быть слишком осторожными со своей стратегией DR.

• Разработка и внедрение эффективных стратегий аварийного восстановления с помощью технологий Citrix. Часть 2. Стратегия
• Разработка и внедрение эффективных стратегий аварийного восстановления с помощью технологии Citrix. Часть 3. Хранилище данных