Как сохранить свою информацию
Законы ненадежности Джилба:
- Компьютеры ненадежны, но люди еще ненадежнее.
- Любая система, зависящая от человеческой надежности, ненадежна.
- Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,- оно конечно по определению.
- В поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.
Данный текст ориентирован в первую очередь на владельцев крупных сайтов, хостинг-провайдеров, администраторов корпоративных баз данных и прочих клиентов датацентров, соответственно под "информацией" мы будем подразумевать исключительно цифровые данные.
Термин "сохранность" более сложен, его можно трактовать как "доступность тем, кому нужно" и "недоступность тем, кому не нужно".
Рассмотрим эти аспекты сохранности, и варианты их обеспечения.
Доступность, "кому нужно".
К примеру у вас есть сервер, на котором сайт, который должен быть доступен потенциальным посетителям максимальное количество времени. Как это можно обеспечить?
Для начала рассмотрим, что угрожает вашему серверу. Чаще всего - неисправность. Вздутые конденсаторы на материнской плате, сгоревший рейд-контроллер, отвалившийся кулер, сотрудник, уронивший ваш сервер при установке, и множество других вариантов (см. 1 и 2-й закон). Для вас нет большой разницы между вариантами, просто для вас сервер перестает быть доступен на неопределенный срок (см. 3-й закон). Учитывая это, вы должны быть готовы к полному выходу из строя сервера в любой момент времени и по любой причине. Конечно, рейд-массивы, резервные блоки питания, брендовое железо и прочие пожиратели бюджета дают некое ощущение надежности, но не более того (см. 4-й закон). По-настоящему гарантии может дать только полное резервирование. В нашем случае это второй такой же сервер, на котором размещена полная актуальная копия всей информации. С точки зрения скорости восстановления оптимально, если второй сервер размещен в том же датацентре. В случае выхода из строя вы просто меняете IP-адрес резервного сервера на IP-адрес основного, и сервис продолжает работать.
В идеале IP поврежденного сервера автоматически перехватывает какой-нибудь Heartbeat на резервном, и момент выхода из строя основного сервера вообще остается незамеченным.
Конечно, это страховка только от локальных проблем с вашим сервером. А есть еще глобальные (см. 3-й закон). Прямое попадание ракеты в датацентр, дурак, отключивший дизель, во время отсутствия основного питания, землетрясение, цунами, эспериментаторы на АЭС, изъятие очень компетентными органами, тракторист, порвавший оптоволоконные каналы, революция, постановление правительства о запрете интернета, и множество других более или менее вероятных неприятностей.
От глобальных проблем можно защититься только максимально географически удалив резервный сервер. Оптимально - на другой континент. Каким образом организовать синхронизацию данных рассматривать не будем, поскольку сильно зависит и от используемого программного обеспечения и от требуемой актуальности данных. Самый примитивный, просто реализуемый, и устраивающий большинство вариант - дамп баз данных и rsync пару раз в сутки. Как организовать переключение потока посетителей - тоже множество вариантов, начиная с малого TTL используемых доменов для быстрого переключения между IP-адресами (имеет и побочные последствия) и заканчивая динамическим DNS.
Без простоя, скорее всего, не обойдется, но и полной потери данных позволит избежать. Еще одна угроза - злонамеренные действия. Ничего им не мешает хакеру, укравшему рутовый пароль, озлобленному бывшему сотруднику, второму "Я" в абстинентном синдроме, удалить всю информацию и на основном и на резервном сервере.
От этого может помочь только еще одна (и недоступная из интернет!) копия. И желательно инкрементальная, т.е. хранить несколько версий от разных дат. И эта копия не должна храниться в очевидных местах, например дома или на работе. Например багажник машины жены - хорошее место. А поскольку оттуда его могут украсть - разумеется, эта копия должна быть зашифрована.
И мы плавно перешли ко второму аспекту - "недоступность тем, кому не нужно". Имейте в виду, любой винчестер с вашей информацией может попасть в посторонние руки.
Вариантов много, это и изъятие милицией "заодно" с соседними серверами, хозяева которых действительно вели незаконную деятельность. И частично вышедший из строя винчестер, который сотрудники датацентра вам заменили на новый и отдали в починку, после чего вся информация вновь стала доступна, и другие варианты.
Выход - не храните никакую информацию нешифрованой. Никакую. Для этого существуют различные технологии, например очень хороший вариант - geli-раздел на FreeBSD. Есть аналоги и для других операционных систем. Это создает неудобства вроде необходимости вводить пароль при старте, но оно того стоит. Копию в багажнике - хотя бы RAR с паролем.
И еще абзац для тех, кто держит корпоративные базы данных в датацентре, и не исключает визита в "маски-шоу" в свой офис. Оформите договор на размещение серверов в датацентре на частное лицо - сотрудника, которому доверяете. И сам договор не держите на работе. Так серверы будет гораздо сложнее найти.
Резюмируя:
При необходимости в одном сервере, их должно быть 3. Первый, основной, размещен в датацентре, и, собственно, работает. Второй, размещен в том же датацентре, выполняет роль быстрой замены первому на случай локальных неприятностей. Третий, максимально удаленный географически, является резервом на случай глобальных проблем.
Резервная копия, недоступная из интернет, которая хранится не дома и не на работе. На всех используемых винчестерах информация хранится исключительно в зашифрованном виде. Как минимум на основном сервере - рейд-массив 1 или 10. Ну или 5-6, если денег не жаль. В случае, если это корпоративная база данных - договор размещения в датацентре оформлен не на компанию, и не хранится в офисе.
Исходя из бюджетных ограничений можно пожертвовать вторым сервером (в ущерб скорости восстановления доступности), третий можно арендовать виртуальный (если производительность позволит), и рейд-массив на первом сервере организовать средствами операционной системы, а не аппаратный.
Разумеется, это не исчерпывающее руководство, и вариантов достижения тех же целей еще много. Например для обеспечения второго аспекта сохранности можно разнести бекенд и фронтенд по разным датацентрам, при этом на дисках фронтенда не хранить ничего, что бы указывало на бекенд, а все необходимые конфиги вливать на виртуальный диск на фронтенде. Для первого аспекта - разместить десяток копий по всему миру, разбросав посетителей раунд-робином на уровне DNS. Фантазия в данных случаях может быть безграничной. Найдите свою золотую середину.