Установлено, что большинство предприятий, переживших крупную необратимую потерю корпоративных данных, прекращают свое существование в течение трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер.
Многие компании пренебрегают защитой стратегических бизнес-приложений от возможных катастроф, но террористическая атака 11 сентября напомнила, что катастрофы неизбежны. Большинство катастроф имеет природное происхождение (в отличие от атак на Нью-Йорк и Вашингтон), но это не делает их безобиднее. Наводнения, землетрясения, сбои питания и пожары — все это достаточно распространенные явления, от которых следует защищать бизнес. Но на практике самую большую опасность для данных представляют обычные человеческие ошибки или злонамеренные действия. Не заботясь о защите корпоративной информации от всех этих факторов, вы ставите под удар не только свою карьеру, но и конкурентоспособность компании, а возможно, и само ее существование.
Реальные потери вследствие недоступности или тем более потери данных чрезвычайно велики. В зависимости от масштаба и характера предприятия час простоя системы может означать потерю от 10 тыс. до 5 млн долл. В бизнесе потери обычно выражаются не только в непосредственном денежном эквиваленте, но и в ущербе для репутации, ослаблении брэнда и утрате благосклонности клиентов.
Хорошо продуманная инфраструктура хранения, обеспечивающая целостность и доступность данных, не обязательно должна стоить баснословных денег — все определяется правильностью планирования. Поэтому для создания «пуленепробиваемой» инфраструктуры хранения корпоративных данных лучше всего строить систему из отдельных «кирпичиков», по модульному принципу.
Модульный подход
Начать следует с определения бизнес-целей вашей компании. Выясните, насколько важны целостность и доступность данных, и согласуйте результаты своего исследования с руководством компании. Например, каково для вашего предприятия максимально допустимое время простоя в год? (Здесь не следует разделять плановые и внеплановые простои, так как с точки зрения пользователей между ними нет никакой разницы.)
Помните также, что не все данные одинаково ценны. Выясните, какие приложения критически важны и должны работать при любых условиях (в эту категорию могут попасть, к примеру, хранилища данных и системы поддержки транзакций). Кроме того, определите, как изменяется ценность данных во времени. Одни данные остаются полезными лишь на протяжении одного-двух дней, после чего их ценность резко снижается; другие нужны на протяжении длительного времени. Иногда закон требует, чтобы данные в течение некоторого времени были доступны в интерактивном режиме, другие данные также иногда приходится сохранять, но не обязательно в режиме онлайн. С учетом подобных соображений вы можете создать инфраструктуру хранения, в которой определены различные уровни ценности данных, а сами данные хранятся в подсистемах, учитывающих эти различия.
Данный подход основан на использовании надежной среды хранения в составе центра обработки данных. Создав такую структуру, позаботьтесь о резервном копировании критически важной информации, которая может потеряться в случае отказа основного хранилища. Резервные копии можно размещать в соседнем здании, а можно и на другом континенте — местоположение определяется особенностями компании и ее географической распределенностью. В любом случае следует иметь в виду, что если данные постоянно доступны, но их целостность не всегда обеспечивается, то ценность таких данных невелика. Нарушения целостности данных могут оказаться фатальными для бизнеса. Таким образом, при создании инфраструктуры хранения следует учитывать требования как к доступности, так и к целостности данных (безопасность также важна, но эта тема выходит за рамки данной статьи).
В сущности, высоконадежная среда хранения состоит из пяти компонентов: массива независимых дисковых накопителей с избыточностью (RAID), резервных каналов, защищенных серверов и приложений, механизма резервного копирования и восстановления и процедур восстановления после аварий.
RAID-хранилище
Защищенные механизмом RAID системы хранения составляют основу вашей «укрепленной» среды. Сегодня большинство RAID-массивов отвечают основным требованиям к целостности и безопасности данных. Система должна обеспечивать уровни RAID 0, 0+1 и 5 (иногда важность приложения вынуждает дополнительно предусматривать уровень 3). В настоящее время поддержка уровня RAID 4 присутствует только в продуктах компании Network Appliance, которые обеспечивают превосходную безопасность и целостность данных. Впрочем, и другие поставщики, в том числе EMC, Compaq Computer, Hitachi Data Systems, Sun Microsystems, LSI Logic, IBM и MTI, предлагают высококачественные решения для обеспечения безопасности.
Выбор продукта определяется на основании таких показателей, как производительность, масштабируемость, управляемость и стоимость; есть и другие параметры оценки поставщиков, но о них — чуть позже. Благодаря устройствам с поддержкой виртуального сетевого хранения, создаваемым такими компаниями, как DataCore Software, FalconStor Software, Veritas Software, StoreAge Networking Technologies и StorageApps (поглощена корпорацией Hewlett-Packard), появилась возможность создавать RAID-решения, просто объединяя дисковые системы. Но в любом случае RAID-система должна обеспечивать полное дублирование и поддерживать горячую замену источников питания, вентиляторов, дисков и контроллеров. Абсолютно необходимо наличие резервного питания и зеркалируемого кэша.
Резервные каналы
Резервные каналы на сервере — еще один важный элемент инфраструктуры, в которой есть хранилище с непосредственным подключением (Direct Attached Storage, DAS) или сеть хранения данных (Storage Area Network, SAN). При наличии DAS все серверы необходимо оборудовать двойными адаптерами ведущей шины (HBA), каждый из которых следует подключить к контроллеру RAID-массива; в SAN все серверы также следует оснащать двумя HBA-адаптерами, подключаемыми к разным коммутаторам Fibre Channel. В более крупных SAN-сетях структура усложняется, но принцип остается неизменным: дублирующие соединения для серверов, коммутаторов и систем хранения.
Для полноты решения следует предусмотреть «многоканальное» серверное ПО, которое при сбое перенаправит трафик от одного HBA-адаптера к другому. Такая возможность предусмотрена в некоторых операционных системах (например, в Solaris); если в вашей ОС ее нет, придется приобрести соответствующее ПО отдельно. В некоторых продуктах с поддержкой данной возможности, например, в PowerPath в компании EMC, предусмотрена балансировка нагрузки.
Защита серверов и приложений
Следующий шаг заключается в обеспечении безопасности серверов и приложений — в большинстве случаев задачу решают путем создания кластеров. Независимо от того, используете вы механизм хранения DAS или SAN, цель остается неизменной: обеспечить перемещение при сбое (fail-over), т. е. автоматический прозрачный перенос приложения со сбойного сервера на исправный.
В простых двухсерверных кластерах после сбоя рабочий сервер обычно работает «за двоих»; при этом снижается производительность приложений, но не их доступность. Однако теперь можно строить кластеры из 16, 32 или большего числа серверов (для этого применяется ПО таких компаний, как Legato Systems и Veritas), в которых после сбоя отдельных серверов нагрузка приложений распределяется между оставшимися работающими серверами, что существенно снижает отрицательное влияние на производительность.
Важно понимать, что отдельные приложения не обязательно работают на всех серверах. Например, сервер A может выполнять функции файлового сервера, а сервер B — сервера базы данных. При отказе «выживший» сервер берет на себя обслуживание обоих приложений. С другой стороны, есть приложения, выполняющиеся на всех серверах одновременно, как, например, на ферме Web-серверов. Главное, чтобы все кластерное ПО могло «видеть» все совместно используемые ресурсы хранения и при любых условиях соблюдать политику безопасности и разграничения между серверами. К счастью, на сегодняшний день кластерное ПО настолько усовершенствовалось, что его вполне можно применять в производственных средах с очень жесткими требованиями.
Программное обеспечение кластеров иногда используется в сочетании с кластерными файловыми системами, что позволяет каждому серверу «видеть» все ресурсы хранения. Не забывайте только, что возможность создавать кластеры из серверов под управлением различных ОС все еще относится к области фантастики.
Убедитесь, что сами серверы дополнительно защищены механизмом резервирования кластерного «пульса». Для защиты некоторых приложений придется приобрести программы-агенты, которые позволят более тонко управлять поведением приложения после перезапуска. Для «доморощенных» или менее популярных приложений можно разработать специальные агенты — программирование подобных компонентов не слишком сложно и занимает не так уж много времени.
Резервное копирование и восстановление
Итак, вы создали «пуленепробиваемую» инфраструктуру с точки зрения подсистемы хранения, серверов и приложений. Я полагаю, вы также не забыли предусмотреть соответствующее резервирование в самой сети. Что же делать дальше? Готовы ли вы приступить к реализации процедур восстановления после катастроф? Нет, не совсем. Сначала следует позаботиться о механизме резервного копирования и восстановления. Задайте себе следующие вопросы. Случалось ли вам неосторожно удалить ценный файл и жалеть, что чуть раньше, на прошлой неделе, вы не позаботились о создании копии? Как часто системные администраторы или администраторы подсистемы хранения удаляли или изменяли данные, которые затем требовались для работы? Что, если перед уходом из компании недовольный сотрудник удалит всю базу данных CRM?
Имейте в виду, что резервирование не самоцель — конечная задача заключается в том, чтобы обеспечить возможность восстановления; ведь многие предприятия регулярно выполняют резервное копирование, но потом (обычно слишком поздно) выясняют, что архивные данные непригодны для восстановления. Поэтому добейтесь от своего поставщика четкого и ясного объяснения, как гарантировать восстанавливаемость данных. Выясните, сколько времени займет восстановление и какие сложности могут возникнуть в ходе этого процесса. Не забудьте, что средства восстановления на уровне томов «не понимают» структуры файловой системы и требуют, чтобы приложение имело полный доступ ко всему тому. На восстановление больших томов могут потребоваться многие часы.
Существует несколько способов решения поставленной задачи — все определяется особенностями бизнеса и важностью наличия самых «свежих» данных. Важный показатель — и время восстановления. Например, в банковском и брокерском деле чрезвычайно важно сохранить все данные — вплоть до самой последней транзакции, выполненной системой. Здесь также критически важно минимизировать до предела время восстановления, ведь потери от простоя в этой отрасли превышают 5 млн долл. в час. Для менее масштабных и оперативных предприятий недоступность данных в течение одного дня зачастую некритична, а восстановление на протяжении одного-двух дней вполне приемлемо.
Мы рассмотрим всего лишь несколько возможностей.
Резервное копирование и восстановление с ленты. В большинстве компаний выполняется еженедельное полное и ежедневное инкрементное резервное копирование на ленту. При создании полной резервной копии обычно требуется остановить систему, если только вы не применяете технологии, позволяющие создавать «моментальный снимок» файловой системы или тома и затем возвращать приложению доступ к файловой системе или тому. Все последующие изменения попадают в следующую копию. При создании статического «моментального снимка» не нужно останавливать приложение — время затрачивается лишь на создание снимка. Правда, производительность приложения при этом снижается.
В традиционных методиках резервного копирования ленты обычно хранят в удаленном месте, чтобы предотвратить их потерю в случае катастрофы в центре данных. Некоторые компании, например, Iron Mountain, специализируются на хранении лент в безопасном месте, обслуживая многие крупные корпорации. Здесь есть два неудобства: время, необходимое для восстановления, в рассматриваемом варианте довольно велико, и восстановление данных возможно лишь на момент создания резервной копии. Финансовым и другим учреждениям, в которых число и объем транзакций огромны, требуются другие методы восстановления «сиюминутной» информации.
Резервное копирование и восстановление с диска. Системы, использующие копии на дисках, предоставляют больше возможностей для организации процедур восстановления после катастроф. В данном случае все определяется тем, где размещается резервная копия —локально или в удаленном месте. Дисковые системы обеспечивают непрерывное резервирование: сначала на диске создается полная резервная копия, а затем на удаленную дисковую систему пересылаются лишь изменения. Поскольку подобные программные продукты «понимают» структуру файловой системы, то восстановление выполняется на уровне файлов. Такие системы особенно полезны для восстановления файлов и документов, в которых поддерживаются версии и сохраняется время внесения изменений. Обеспечивается полное восстановление вплоть до последней зарегистрированной транзакции. Независимо от месторасположения архивных дисков — удаленного или локального — данные с резервного диска, как правило, копируются еще и на ленту.
Резервное копирование с диска на диск будет получать все большее распространение, этому, кроме прочего, поспособствует появление технологии iSCSI, которая поддерживает доступ к информации на уровне отдельных блоков через IP-сети. Многие компании вскоре возьмут iSCSI на вооружение и перенесут резервные данные с дорогих высокопроизводительных RAID-систем высокой доступности на более дешевые дисковые системы. Однако и ленты будут использоваться еще довольно продолжительное время.
Восстановление после катастроф
Итак, мы подошли к заключительному шагу: к защите самого центра данных. Существует несколько методик обеспечения безопасности центра данных. Какое решение будет правильным, станет ясно после определения того, какие данные критически важны, сколько новой информации создается в течение дня, каковы требования к скорости восстановления после катастрофы, каким объемом данных вы готовы пожертвовать и сколько денег вы готовы потратить.
Синхронное зеркалирование, или репликация. Существуют две методики поддержки репликации — создание "зеркал" на одной или нескольких системах хранения и репликация через серверы.
Компании EMC, IBM и Hitachi Data Systems предлагают программы, поддерживающие репликацию всех изменений между томами основной и удаленной подсистем по каналам ESCON (Enterprise Systems Connection), ATM (Asynchronous Transfer Mode) или IP-сетям. Сами серверы (хосты) в переносе данных не участвуют. Файловые системы не поддерживаются — изменения регистрируются на уровне блоков, а восстановление выполняется на уровне отдельных томов. Изменения не фиксируются на основном томе, пока они не скопированы и не подтверждены на удаленном томе. Это приводит к снижению производительности приложений, работающих в основном местоположении, причем с увеличением расстояния ситуация ухудшается. Производительность также зависит от быстродействия сети, в которой расположены системы хранения, однако целостность данных обеспечивается полностью. Транзакции на обеих системах согласованы; при полной потере центра данных приложения могут продолжить работу, используя данные зеркального тома в резервном центре.
Если не обращать внимания на снижение производительности, высокую стоимость и довольно длительное время восстановления, репликация представляется самым безопасным решением для обеспечения восстановления после катастроф. (Обратите внимание: в основном и резервном центрах следует оборудовать идентичные хранилища.) Можно также разработать решение с репликацией по схеме «один-ко-многим», но такой подход очень дорог. Переключать серверы придется вручную, если только не развернуть кластеры в WAN-сетях.
Репликацию иногда осуществляют через серверы. В этом случае информация об изменениях тома пересылается по сети с локального на удаленный сервер и затем — на резервный том. Как и в предыдущем варианте, транзакция в основной системе не завершается, пока удаленная система не сохранит изменения и не будет получено подтверждение. Страдает производительность приложений и работы подсистемы хранения, а большие расстояния лишь усугубляют ситуацию.
Преимущество данного подхода в том, что в основном и удаленном центрах можно установить различные системы хранения. Например, основное помещение можно оборудовать высокопроизводительной дисковой системой высокой готовности, а на удаленном объекте разместить дешевую систему. Но в любом случае нужно дополнить эту дешевую систему хранения сопоставимым сервером и создать аналогичную сетевую среду, чтобы в случае аварии немедленно запустить приложения в резервном офисе. Поскольку доступ к данным осуществляется на уровне файловой системы, возможно восстановление как на уровне отдельных файлов, так и всего тома. Другое преимущество заключается в сравнительной простоте и дешевизне реализации репликации по схеме «один-ко-многим».
Поддержка асинхронных зеркал. Когда жертвовать производительностью в пользу поддержки синхронных зеркал нельзя, вы можете воспользоваться асинхронными зеркалами. В этом варианте изменения фиксируются в основном офисе по мере их появления и одновременно «сбрасываются» по сети и асинхронно записываются на удаленном томе. Хотя в таком варианте влияние на производительность минимально, удаленная система отстает от основной, причем время запаздывания определяется объемом данных «в пути» — чем больше расстояние, тем большим может быть отставание в случае сбоя. Хотя описанный подход недопустим в критически важных для бизнеса приложениях, может оказаться, что для многих других приложений он вполне годится.
Поддержку процедур восстановления после катастроф до недавних пор могли позволить себе лишь крупные корпорации, однако теперь метод асинхронного зеркалирования позволяет даже небольшим компаниям всерьез задуматься о планах восстановления после аварий. Подобные решения недороги, а сохранить после катастрофы данные, устаревшие всего на несколько секунд, все-таки лучше, чем потерять всю информацию.
Восстанавливайтесь и процветайте
Мы надеемся и молимся, чтобы события 11 сентября не повторились никогда. Но мать-природа не перестанет демонстрировать свою мощь в форме наводнений, землетрясений и других катастроф, да и человеческие ошибки неизбежны в любом бизнесе. Построенная на надежном фундаменте инфраструктура хранения существенно продвинет вас в обеспечении жизнеспособности вашего предприятия, невзирая на козни природы и людей.
| Арун Танеджа (Arun Taneja) — старший аналитик компании Enterprise Storage Group, специализирующейся в области технологий хранения. Имеет 25-летний опыт работы в области серверов и систем хранения.
С ним можно связаться по e-mail: arunt@enterprisestoragegroup.com. |
Пять шагов на пути к восстановлению
|
