Планування катастрофи

Я працюю в невеликій маркетинговій компанії, яка також займається веб-дизайном та розробкою. Ми розміщуємо всіх наших клієнтів з веб-дизайну та розробки на спеціальному сервері в Hostgator. У нас є виділений сервер з жорсткими дисками, налаштованими RAID 1. Ми також робимо резервні копії щотижня, які автоматизуються через cPanel та завантажуються автоматизованим програмним забезпеченням FTP на місцевому рівні.

Сьогодні ми обговорювали, що робити, якби в Хостґаторі трапився якийсь катастрофічний збій. Це може бути сервер, який вибухнув, у Hostgator виникли серйозні проблеми з мережею, ФБР здійснив один із відомих набігів "взяти кожен сервер, який ми бачимо" тощо. В основному будь-який сценарій, де очікується тривалий відключення. Потім ми підняли його на наступний рівень і задалися питанням, що б ми зробили, якщо у Hostgator буде розширений відключення, і ми не змогли отримати доступ до наших місцевих резервних копій. Це може бути пов’язано з пожежею, повені тощо. Я знаю, що шанси нашого сервера знижуються протягом тривалого часу, і наші локальні файли, одночасно недоступні, віддалені, але все, що потрібно, - це лише двапогані речі трапляються, і саме там ми б стояли. (Якщо ви коли-небудь набували плоску шину і дізналися, що ваша запчастина була плоскою або відсутньою, ви знаєте, наскільки легко може статися одночасно дві погані речі).

Потрібно говорити, що ми хочемо бути готовими до подій типу "найгірший випадок", оскільки це майже напевно позбавить нас бізнесу. Тож два мої питання:

1. Що ми могли б зробити, щоб бути готовим до тривалого відключення від Hostgator? Ідеальний сценарій матиме веб-сайти наших клієнтів, і, сподіваємось, електронні листи швидко працюватимуть.

2. Що може скласти надійний план резервного копіювання, щоб важливі дані ніколи не втрачалися? Ідеальне рішення буде автоматизоване.

Ви можете припустити, що вартість не є проблемою у ваших відповідях, але чим доступніші рішення, тим краще.

Я б запропонував вам:

1. Автоматичне дзеркальне відображення всього вмісту та конфігурації вашого основного сервера на вторинному сервері резервного копіювання у повністю окремій мережі в іншому центрі обробки даних. Використовуйте RSync, FXP, cPanel voodoo або будь-який інший метод для автоматизації синхронізації.

2. Використовуйте перемикання помилок DNS для автоматичного маршрутизації трафіку на резервний сервер, якщо сервер Hostgator виявиться невідповідним.

Це означає, що у вас постійно виникає "гаряча" резервна копія, яка чекає, якщо це станеться найгірше, а не "холодна" резервна копія, яка вимагає вручну втручання та сильних розбіжностей і паніки. Це також означає, що ваші клієнти ніколи не будуть знати, що їх сайт пішов вниз, перш ніж ви зробили, що може бути засмучує для всіх.

Ви можете налаштувати відмовостійкий DNS з допомогою провайдера , такими як DNS Made Easy . Для кожного домену ви розміщуєте, ви б налаштувати до п'яти резервних IP - адрес, по одному для кожної з резервних серверів. Як тільки це зроблено ...

1. DNS Made Easy перевіряє ваш основний сервер протягом двох-чотирьох хвилин, і якщо він не виявляє відповідь, він спрямовує трафік на вторинну IP-адресу.

2. DNS Made Easy продовжує перевіряти основний сервер. Коли він з'явиться, він перенаправить трафік на перший сервер, або - якщо вам зручніше - тримати його в резервній копії, поки ви діагностуєте, що пішло не так і виправите основний сервер.

Звичайно, це рішення підвищить ваші операційні витрати, які вам доведеться якось передати клієнтам, але, якщо ви працюєте в галузі, де простої дозволять вам позбавитись бізнесу, платити за сервер, що значною мірою є зайвим, можливо, варто це тим часом рятує компанію.

Поза цим:

Дублікат, дублікат, дублікат

Чим більше незалежних резервних копій, тим краще. Я зберігаю віддалені резервні копії на локальному жорсткому диску, який відображається на зовнішньому жорсткому диску, в Dropbox, сховище git та віддалений обліковий запис FTP. Не ризикуйте. Дублюйте стільки, скільки зможете. Якщо вам доведеться відновити вручну резервну копію, краще мати вибір із п’яти, ніж вибір одного. Параноїя недооцінена.

Практикуйте відновити резервні копії вручну

Якщо ви ніколи не намагалися відновити один із резервних копій, як ви знаєте, що вони працюють? Варто зробити екстрені дрилі, щоб побачити, що станеться у разі відмови ваших автоматизованих процедур.

• Cloudflare, який забезпечує функції безпеки та кешування, щоб підтримувати сайти, коли ваш сервер не працює. (Вони дзеркально відображають ваш сайт і обслуговують його зі свого кеша, який поширюється на глобальному рівні, а не безпосередньо з вашого сервера.)
• Захисник коду, який забезпечує автоматичне резервне копіювання та відкат коду веб-сайту (лише FTP).
• Автозавантаження веб-сайтів, яка забезпечує автоматичне резервне копіювання та відкат коду веб-сайту, даних електронної пошти та інформації MySQL за допомогою резервного копіювання cPanel. Зауважте, що цим керує Hostgator, тому це не обов'язково підходить, якщо ви також розміщуєте свій сайт разом з ними, але може допомогти іншим.

Зокрема, Cloudflare виглядає так, що було б корисно уникнути простоїв та загалом покращити чутливість сайту.

Відновлення стихійних лих може бути величезним завданням, особливо при роботі з декількома серверами, сайтами та базами даних. Два ключових пункти, які слід враховувати при обраному рішенні, - це завдання часу відновлення (RTO) та цілі точки відновлення (RPO).

RTO - це по суті очікування того, скільки часу повинно пройти, поки сайти не будуть резервні. Якщо у вас є RTO хвилини-дві (або менше), то вам слід розглянути рішення відповідно до того, що запропонував Нік, що передбачає реплікацію ваших файлів і даних у реальному часі у вторинний центр обробки даних та автоматичне відключення DNS, яке може робити з платною послугою або з обладнанням в обох центрах обробки даних (наприклад, BIG-IP Global Traffic Manager)від мереж F5. Це може бути дорогим, але багато в чому залежить від відповіді на питання "Яка вартість простою?" Якщо ваш RTO - це кілька годин, а то й декілька днів, тоді ви можете розглянути процедури відновлення після аварій, які можуть включати в себе більше ручного залучення, наприклад, підключення серверів до Інтернету, перемикання DNS тощо.

RPO - це, як часто робиться резервне копіювання та скільки даних ви готові втратити у випадку катастрофи. Якщо зміни у вмісті та / або даних трапляються часто, то, швидше за все, у вас буде RPO, можливо, хвилин або години, і ви можете мати справу з реплікацією в режимі реального часу або резервними копіями високої частоти. Якщо вміст не змінюється так часто, або у вас є клієнти, яким не обов’язково байдуже, що вони втрачають дані протягом декількох днів, ваші резервні копії можуть траплятися рідше.

Як я вже згадував, я згоден з великою частиною того, що мав сказати Нік. Ще одна альтернатива, яку ви можете розглянути, - це використання хмарних послуг від одного з найбільших хмарних постачальників, таких як Rackspace або Amazon. Зокрема, обидва ці постачальники мають потужну інфраструктуру, щоб мати змогу впоратися з будь-якими катастрофами, що на них стикаються. З чимось на зразок хмарного сайту або хмарного сервера (терміни, які використовує Rackspace), ви маєте перевагу в тому, що можете також масштабувати, і не потрібно обов’язково турбуватися про його фізичний апаратний аспект.

У Rackspace також доступні спеціальні параметри, де ви можете змішувати свою інфраструктуру, поєднуючи хмарні сервери, фізичні сервери та файли хмари як частина вашого рішення. Гібридний підхід може щось враховувати залежно від потреб вашого клієнта, якщо ви не хочете використовувати один розмір, який відповідає всім підходам.

Якщо це допомагає, на сайті Rackspace також є сторінка, присвячена відновленню аварій, яку можна знайти тут . (Також для запису я не пов'язаний з Rackspace, але раніше користувався їхніми послугами).

Сподіваюся, що це допомогло.

EDIT : Думаю, що це може допомогти, якщо ви оцінюєте хмарні рішення. Звіт про магічний квадрант Gartner щодо інфраструктури та як сервіс та веб-хостинг може дати вам деяке уявлення про інших постачальників рішень.

Повна реплікація сервера на іншому об'єкті іншого хостинг-компанії здається найбільш очевидним рішенням.

Файли можна синхронізувати з такими інструментами, як rsync та unison. Резервні копії SQL можуть бути також синхронізовані, а потім завантажені в невідомий db скриптами.

Переконайтеся, що ви керуєте версією всього коду за допомогою сховища вихідного коду (SVN або GIT). Ви використовуєте SVN чи GIT?

Ви можете отримати обліковий запис (безкоштовний або платний) у сховищі сторонніх розробників, як-от Project Locker , і якщо ви працюєте з версією всього коду під час роботи, по суті у вас є все резервне копіювання до вашого сховища, яке знаходиться в третьому місці . Тим самим ще більше знижуючи ваші шанси (майже до нуля) втратити одразу всю роботу.

Ви можете виконувати свої SVN-зобов’язання / каси через командний рядок, або через такий клієнт, як Versions (для Mac) або TortoiseSVN (для Windows).