Что делать, если торнадо прошел через ваш дата-центр?
В прошедшие выходные у нас были сильные штормы здесь, в Вирджинии, и, конечно, кризис в Японии - напоминание о том, что в одно мгновение все может пойти плохо! Вопрос, который я задаю себе: "Что, если торнадо поразит мой центр обработки данных, я готов?"
У меня есть отличные системы резервного копирования "в моей стойке", включая резервное копирование на ленту. Поскольку дата-центр не находится близко, перемещение лент за пределы площадки невозможно. То, что я хотел бы найти или создать, - это система, которая по расписанию может создавать резервные копии критически важных элементов, таких как веб-сайты, базы данных, и копировать их удаленно, т.е. мой сервер дома. У меня есть FIOS с услугой 35 Мбит, поэтому у меня есть широкополосный доступ, и мне нужна "система", чтобы сделать это. Я программист, так что я мог бы создать что-то, что FTP отключит информацию по расписанию, но мне любопытно, есть ли что-то, что могло бы удовлетворить эту удаленную резервную копию сейчас? Мои SQL-серверы резервируются в массивы хранения, я могу их отключить или даже запланировать синхронизацию моего SQL-сервера с производственными серверами по расписанию. Я использую Windows Server 2008 R2 и SQL Server 2008 R2.
Что вы все порекомендуете для стратегии за пределами площадки в условиях кризиса, такого как стихийное бедствие, выбивающее наш центр обработки данных? Вы готовы? Я надеюсь, что другие задают себе этот вопрос и учатся на этих стихийных бедствиях, которые мы видели слишком часто.
5 ответов
Ваши варианты должны быть продиктованы вашими соглашениями об уровне обслуживания с вашими клиентами и ограничены вашим бюджетом.
Как минимум, вы должны иметь резервные копии всех важных данных за пределами сайта. То есть сегодня любые данные, которые вы не можете воссоздать с нуля, должны храниться где-то еще. Резервные копии в автономном режиме лучше: резервные копии в режиме онлайн или репликация могут помочь в случае торнадо, но что произойдет, если злой сотрудник удалит базу данных или уничтожит файловую систему?
Исходя из базовых резервных копий в автономном режиме, вы можете начать изучать варианты, которые ускорят восстановление в обмен на более высокую стоимость. Здесь существует огромное количество вариантов, от одного хоста для оперативного резервного копирования, который вы описываете, вплоть до полностью реплицированных сред с синхронной репликацией данных, работающей активно (-активно)+ для почти нулевого времени простоя.
Вы обнаружите, что восстановление с нуля будет намного проще, если вы аккуратно отделите свои данные от инфраструктуры. Например, восстановление с нуля будет намного, намного быстрее, если вы будете использовать системы типа puppet или chef, а не вручную. Переделать всю работу, которую вы вложили в построение ваших систем, будет намного быстрее, если вы сможете максимально автоматизировать. Разделение данных также уменьшает объем данных, которые необходимо создать для резервного копирования: не выделяйте гигабайты ОС, если вам действительно нужно всего несколько мегабайт системных настроек и данных приложений.
Варианты могут быть довольно дорогими, поэтому вам необходимо определить, сколько ваша компания готова потратить на восстановление после сбоев, и сколько времени простоя могут терпеть ваши клиенты. Исключите варианты, которые слишком дороги или слишком медленны для ваших клиентов.
После того, как вы выберете решение для аварийного восстановления, обязательно попробуйте его на практике. Я бы рекомендовал, по крайней мере, один раз в год или когда ваша архитектура меняется, в зависимости от того, что происходит чаще.
Непрерывность бизнеса намного шире, чем просто обеспечение доступа к читаемым резервным копиям. Но ограничивая сферу ответа только этим, в конечном итоге он будет жизнеспособным только в том случае, если сквозная пропускная способность от центра обработки данных до места резервного копирования достаточно велика для обработки объема изменений данных.
Когда вы говорите о центре обработки данных, то для большинства людей это гигаайт данных в неделю.
IME, even on a small scale the best solution is a distributed (or mirrored) operation. Plan it right and there should be little cost overhead compared with a single datacenter.
But if you must copy all the data out to a standby location or even just to remote storage, then
1) don't use FTP - it's just the wrong way to do it for lots of reasons
2) for generic files, use something like rsync which is optimized for the purpose
3) for databases, look at the tools available specifically for your DBMS - the file structure can change massively without the data changing a lot. NB this incldues MSWindows registry and MSAD data.
У нас есть несколько отдельных активных / активных или активных / полуактивных центров обработки данных, расстояние между которыми>50 миль, различные поставщики электроэнергии, системы безопасности, разнесенные каналы связи по 10 Гбит / с между ними, о, и мы также поставляем наши резервные диски между ними. Это для нас.
У нас есть VPN от нашего офиса до нашего внешнего центра обработки данных. В удаленном центре обработки данных у нас есть сервер, на котором смонтирован общий сетевой ресурс, который мы настраиваем в качестве места назначения в нашем программном обеспечении для резервного копирования (мы запускаем Symantec BackupExec), т.е. \OFFSITEDATACENTER\OFFSITESTORAGE
Затем мы делаем - полное резервное копирование в выходные дни в это место
- постепенно каждый вечер
А также наши обычные "локальные" резервные копии
Мы также запускаем VMWare VDR, чтобы каждую неделю снимать образы наших основных серверов, которые помещаются на диск SATA емкостью 2 ТБ, зашифрованный с помощью FreeOTFE, который я беру домой каждую неделю.
Особенности обработки определенной схемы резервного копирования были рассмотрены до тошноты здесь и в других местах. Я собираюсь подойти к этому вопросу с более общей точки зрения общих рекомендаций, чтобы помочь вам решить, как подходить к аварийному восстановлению. У меня было довольно много ситуаций, когда нужно было планировать на случай, если центр обработки данных станет дымящимся кратером. К счастью, нам пришлось использовать его только один раз. Наиболее важные вещи, которые нужно запомнить:
1) Не тратьте свое время на попытки переобучиться и заставить все переключаться с точностью <1 мс, если не нужно. Полный провал такого масштаба обычно оправдывает восстановление за несколько часов.
2) Как следствие № 1, убедитесь, что ожидания реально определены и закодированы где-то в политике. Важно установить поставленную цель, поскольку время восстановления очень важно, поскольку вы можете тратить неограниченное время, а получение средств "еще лучше".
3) Приоритет ваших систем. План восстановления должен строиться вокруг окончательного списка важности каждой системы. Не пропустите очевидные вещи, такие как установка DNS и AD перед остальными серверами Windows.
4) Если это не вне сайта И вне сети, это просто копия. Это идет в ногу с другой ключевой вещью, которую нужно помнить: RAID - это не план резервного копирования.
5) Тест, Тест, ТЕСТ! Проверьте каждый сантиметр вашего плана, который вы можете. Если вы можете сэкономить на выходных на период обслуживания, отключите восходящую линию и / или питание здания и проверьте время реакции и эффективность вашей команды. План аварийного восстановления, который никогда не проверялся, - это просто желаемое за действительное.