НОВОСТИ
О КОМПАНИИ
НАШИ КЛИЕНТЫ
ПОДБОР СЕРВЕРА
УСЛУГИ
ТЕХПОДДЕРЖКА
СКАЧАТЬ ПРАЙС
КОНТАКТЫ
г. Киев, ул. Куреневская, 21-Г тел. (044) 228-54-77
Поиск
Серверное оборудование
Серверные платформы
Готовые серверы
Системы хранения данных
Контроллеры
Серверные компоненты
Сетевое оборудование
Системы доступа и KVM
Архив товаров
Готовые серверы (Архив)
Серверные платформы (Архив)
Серверные компоненты (Архив)
Системы хранения данных (Архив)
Системы Microcloud (Архив)
ПО (Архив)
IP-телефония (Архив)
Корзина пуста
Курс валют:
гривны нал.: 1 $ = 26.40 грн.
гривны б/нал.: 1 $ = 26.40 грн. с НДС

Показывать цены в:
 

Обратите внимание:
Для некоторых групп товаров безналичный курс может отличаться. Уточняйте информацию у менеджера.

 
Купить сервер Supermicro

Планирование защиты и восстановления данных в случае катастроф. Часто задаваемые вопросы (FAQ)

Введение

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

1 «Нужен ли нам план восстановления в случае катастрофы?»

     У вас есть страховой полис? Ваш автомобиль застрахован? Застраховано ли ваше предприятие на случай пожара или краж? В таком случае, почему бы вам не застраховать ваши данные? Большинство предприятий признают, что их корпоративные данные являются жизненно важными для компании.
     Все мы хотим избежать катастроф, но, к сожалению, они случаются. В сегодняшний информационный век почти нет компаний, которые могут допустить потерю значительных объемов данных или оставаться в режиме offline дольше короткого временного периода. Заказчики рассчитывают, что большинство компаний в состоянии возобновить предоставление услуг в очень короткий промежуток времени.
     Исследования показывают, что даже очень небольшой простой может нанести компании серьезный ущерб. Воздействовать на доходы. Воздействовать на клиентов. Нанести ущерб репутации компании. Более длительный простой может попросту закрыть предприятие. Статистика меняется в зависимости от отрасли. Тем не менее, тенденция одна.
     Корпоративные IT инфраструктуры, и в особенности корпоративные данные, являются критичными в функционировании предприятия. В большинстве сред почти все данные считаются критичными. Часто электронная почта является одним из наиболее критичных приложений. Следовательно, катастрофы в основном фатальны для предприятий, не имеющих плана восстановления в случае катастроф. Наряду с тем, что объем и уровень детализации могут разниться, у большинства предприятий должна быть некоторая форма плана восстановления в случае катастроф DRP (Disaster Recovery Plan).

2 «Не являются ли планы восстановления в случае катастроф чрезвычайно дорогими?»

     Как упомянуто выше, размер, сложность и уровень детализации в DR планах значительно различаются. Что касается большинства планов, важно определить требования и цели, и затем строить план в соответствии с этими целями. Учтите, что вам действительно необходимо, и сколько вы будете готовы платить.
     Например, ключевым фактором, который необходимо учесть, являются требования к точкам восстановления RPO (Recovery Point Objective), определяющие количество точек восстановления, в которых вы в состоянии восстановиться. Вы можете захотеть учесть это на основании взаимодействия прикладных систем. В простом DR плане время между точками восстановления составляет не более чем 48 часов. Другими словами, я могу провести восстановление в случае любого происшествия, и потерять данные максимум – за последние 48 часов. В других средах вы можете решить, что не можете допустить потерю более чем 5 минут для сохранности данных. Это важно для понимания вашего показателя RPO.
     Другим фактором, который надо учесть, является требование к времени восстановления RTO (Recovery Time Objective), этот показатель определяет количество времени, которые отнимет восстановление. Формулируя иначе, как много времени вы можете находиться в режиме offline.
     Установив ваши требования, вы можете начинать применять технологии, соответствующие им. В разделах ниже показано, как затраты на DRP могут быть значительно снижены и сделаны доступными.

3 «Должен ли DR узел восстановления в случае катастроф быть физическим зеркалом главного узла?»

     Это не всегда так. Очень малый процент внедрений планов DR требует создания полного физического зеркала оборудования, сетей, людей и других ресурсов в DR узле. Не все приложения и операции в главном узле предназначены для решения критически важных задач. Следовательно, не все они должны быть восстановлены немедленно. Некоторые приложения и операции могут допускать не такие требовательные показатели RPO и RTO, как другие.
     Например, если внутренний научно-исследовательский отдел разработал приложения для внутреннего использования, их функции могут быть далеки от критичных. Следовательно, DR узел может не допускать использования емкости хранилища, мощностей серверов и рабочей среды для этого отдела.
     Приоритеты, установленные для каждого приложения и операции, оборудования и ресурсов, должны быть определены для узла DR. В большинстве случаев, главный узел хорошо оборудован, предоставляя адекватную мощность, чтобы справиться с пиковыми нагрузками плюс некоторый ее избыток. Тем не менее, узлу DR обычно не требуется быть сконфигурированным для поддержки дополнительных нагрузок. За счет этого конфигурация DR может быть намного более рентабельна, чем основной узел. В случае катастрофы, узел DR будет полностью функционален на протяжении небольшого временного периода, требуемого для поддержки функционирования. Если невозможно вернуться к основному узлу в короткий промежуток времени и ожидаются периоды пиковой загрузки, может быть выполнена модернизация узла DR.
     Кто-либо может возразить, что приложения хранения несут ответственность за зеркалирование данных на узле DR, функционируя только с такими же системами хранения, и, следовательно, менее дорогие решения недоступны. Это действительно было так несколько лет назад, когда поставщики систем хранения придерживались более закрытого системного подхода. Тем не менее, в настоящее время некоторые независимые поставщики программного обеспечения предлагают зеркалирование между гетерогенными устройствами хранения, обеспечивая возможность выбора наиболее подходящей системы хранения для узла DR, независимо от производителя. В дополнение к этому, эффективность решений зеркалирования поддерживается зеркалированием высокопроизводительных устройств на менее производительных решениях.

4 «Предназначен ли план DRP только для физических катастроф?»

     Нет. Если бы это было так, вы были бы не в состоянии восстановить данные в случае вирусной атаки или тотального повреждения данных в связи с дефектами приложения.
     Исследования показали, что более 93% ошибок являются скорее «логическими», чем «физическими» сбоями. Наряду с некоторыми из этих ошибок, которые не считаются «катастрофами», другие (например, вирусы, повреждение данных или случайное удаление файла) могут быть столь же разрушительны, как физическая катастрофа. Итоговый результат тот же – предприятие выводится в режим offline.
     Хороший план защиты данных требует обеспечить их быстрое восстановление, как при физических, так и при логических сбоях на главном узле, наряду с гарантией того, что логические ошибки не распространяются на узел DR.
     Наиболее общеизвестной и эффективной защитой от логических сбоев является использование “моментальных снимков” (snapshot). Некоторые поставщики сейчас предлагают snapshot малого объема, которые используют емкость хранилища только для изменений, сделанных после самого последнего snapshot. Такие snapshot могут применяться для восстановления в течение нескольких секунд, исключая необходимость тратить часы на восстановление с использованием традиционных ленточных (или дисковых) решений резервного копирования.

5 «Обеспечивают ли синхронные зеркала лучшую защиту, чем асинхронные?»

     Как синхронные, так и асинхронные зеркала имеют преимущества и недостатки. Лучшее решение зависит от того, что вы пытаетесь выполнить. В синхронном зеркале данные DR узла идентичны данным главного узла. Тем не менее, это не гарантирует, что использующие эти данные приложения будут успешно восстановлены. Например, базы данных не всегда могут восстановить операции из любой временной точки “моментального снимка” данных. Базам данных обычно требуется целостность (непротиворечивость) данных для возобновления операций. У некоторых баз данных есть отнимающие время внутренние процедуры для перезапуска вместе с нецелостными данными, и статистически они не совсем надежны.
     Есть некоторые поставщики, предлагающие решения асинхронного зеркалировакния, основывающиеся на snapshot малых объемов. Для сбора изменений задаются предварительно определенные временные интервалы snapshot. Эти изменения пересылаются на узел DR. Snapshot малых объемов являются стандартными snapshot, которые могут использоваться серверами как главного узла, так и узла DR. Они также обеспечивают защиту от логических сбоев (см. выше).
     Предполагается, что вы выбираете поставщика, который предлагает как синхронное, так и асинхронное зеркалирование, давая вам гибкость в применении технологии, которая наиболее соответствует вашим потребностям.

6 «Как далеко следует располагать узел DR?»

     Недавние события, такие как 11 сентября, цунами и ураган Катрина, показывают, что близкий к основному узлу узел DR может быть недостаточным подходом к решению проблемы. В этих случаях целые регионы были поражены катастрофой, и единственным способом восстановить функционирование – был узел DR, расположенный далеко от основного узла.
     Использование асинхронного зеркалирования позволяет создать зеркало на другой стороне земного шара. Решения асинхронного зеркалирования очень эффективны и могут работать по IP линиям с низкой пропускной способностью. Некоторые поставщики предлагают эту возможность даже без какого-либо дополнительного оборудования. С другой стороны, синхронному зеркалированию обычно требуются линии Fibre Channel (FC), которые ограничены приблизительно 10 километрами. Тем не менее, некоторые производители предлагают сейчас расширения FC, которые могут достигать более чем 1000 миль.     Опять-таки, рекомендуется, чтобы вы выбрали поставщика, который предлагает как синхронное, так и асинхронное зеркалирование, давая вам гибкость в применении технологии, наилучшим образом соответствующей вашим запросам.

7 «Может ли узел DR использоваться не только для зеркалирования?»

     Да. Если бы это было не так, узел DR подавляющую часть времени был бы пустой тратой громадных ресурсов. Целью предприятия является получение максимальной отдачи ресурсов. Наличие серверов, хранилища, сетевых и человеческих ресурсов, находящихся в праздном ожидании сбоя не являлось бы хорошим использованием ресурсов. С другой стороны, если вы сможете включить эти ресурсы в работу, вы можете начинать окупать план DR сверхурочно.

Пример 1 – удаленное резервное копирование данных. Ленты резервного копирования обычно отправляются в удаленный офис, а во многих случаях они отправляются в узел DR. Кроме того, резервное копирование отнимает ресурсы системы, хранилища, сети, сетей SAN и LAN. С того момента, когда на узле DR имеется обновленная версия данных, резервное копирование на ленту может быть выполнено там, освобождая ресурсы основного узла.

Пример 2 – отделы разработки и тестирования. У многих организаций есть научно-исследовательские отделы, которые разрабатывают и тестируют приложения и утилиты для внутреннего и внешнего использования. Этим отделам часто требуется обновленная версия данных для выполнения тестов. Так как на узле DR уже есть необходимое оборудование и требуемые данные, лучше использовать его, чем закупать дополнительное оборудование в основной узел.

     Это лишь два из множества примеров того, как узел DR может быть использован, если инструменты DR поддерживают чтение и запись данных. Убедитесь, что ваше решение поддерживает эти возможности.

Резюме

    Реализация плана DR во многом похожа на страхование. Предприятие может функционировать без него, но риски слишком высоки. Защита данных является реальным требованием рынка и многие новые, доступные сейчас решения предоставляют развитую функциональность, ранее не доступную. Ко многим мифам, годы назад доминирующим в дискуссиях, уже не прислушиваются. У проблем, которые не так давно считались неразрешимыми (или слишком дорогостоящими в их разрешении), сейчас есть допустимые по средствам решения. Перешагивая через мифы и выбирая правильные решения, каждое предприятие может создать рентабельный план DRP, наилучшим образом соответствующий его требованиям

© 1993-2018 Компания SER - Все права защищены