Законы ненадежности Джилба:
1. Компьютеры ненадёжны, но люди ещё ненадежнее.
2. Любая система, зависящая от человеческой надёжности, ненадёжна.
3. Число ошибок, которые нельзя обнаружить, равно бесконечности, по сравнению с числом ошибок, которые можно обнаружить.
4. В поиски повышения надёжности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.

        Данный текст ориентирован в первую очередь на владельцев крупных сайтов, хостинг-провайдеров, администраторов корпоративных баз данных и прочих клиентов Дата-центров, соответственно под "информацией" мы будем подразумевать исключительно цифровые данные.

        Рассмотрим эти аспекты сохранности, и варианты их обеспечения. Термин "сохранность" более сложен, его можно трактовать как "доступность тем, кому нужно" и "недоступность тем, кому не нужно".

Доступность "кому нужно".

        К примеру у вас есть сервер, на котором есть сайт, который должен быть доступен потенциальным посетителям максимальное количество времени. Как это можно обеспечить? Для начала рассмотрим, что угрожает вашему серверу. Чаще всего - неисправность. Вздутые конденсаторы на материнской плате, сгоревший RAID-контроллер, отвалившийся кулер, или сотрудник, уронивший ваш сервер при установке, а также множество других вариантов (см. 1 и 2-й законы Джилба). Для вас нет большой разницы между вариантами, просто для вас сервер перестает быть доступен на неопределённый срок (см. 3-й закон Джилба). Учитывая это, вы должны быть готовы к полному выходу из строя сервера в любой момент времени и по любой причине. Конечно, RAID-массивы, резервные блоки питания, брендовое железо и прочие пожиратели бюджета дают некое ощущение надёжности, но не более того (см. 4-й закон Джилба). По-настоящему гарантии может дать только полное резервирование. В нашем случае это второй такой же сервер, на котором размещена полная актуальная копия всей информации. С точки зрения скорости восстановления наилучший вариант это когда второй (резервный) сервер размещён в том же Дата-центре, что и первый (рабочий) сервер. Тогда в случае выхода из строя первого (рабочего) сервера вы просто меняете IP-адрес резервного сервера на IP-адрес рабочего сервера, и сервис продолжает работать.В идеале IP-адрес повреждённого сервера автоматически перехватывает какой-нибудь Heartbeat на резервном сервере, и момент выхода из строя основного сервера вообще остается незамеченным.

        Конечно, это страховка только от локальных проблем с вашим сервером. А есть еще глобальные (см. 3-й закон). Прямое попадание ракеты в Дата-центр; дурак, отключивший дизельный генератор, во время отсутствия основного питания; землетрясение, цунами, экспериментаторы на АЭС; изъятие серверов очень компетентными органами; тракторист, порвавший оптоволоконные каналы; революция, постановление правительства о запрете интернета, и множество других более или менее вероятных неприятностей.

        От глобальных проблем можно защититься только максимально географически удалив резервный сервер. Оптимально - на другой континент. Каким образом организовать синхронизацию данных рассматривать не будем, поскольку сильно зависит и от используемого программного обеспечения и от требуемой актуальности данных. Самый примитивный, просто реализуемый, и устраивающий большинство вариант - дамп баз данных и rsync пару раз в сутки. Как организовать переключение потока посетителей - также множество вариантов, начиная с малого TTL используемых доменов для быстрого переключения между IP-адресами (имеет и побочные последствия) и заканчивая динамическим DNS. Без простоя, скорее всего, не обойдётся, но и полной потери данных позволит избежать.

         Ещё одна угроза - злонамеренные действия. Ничего не мешает хакеру, укравшему root-пароль, озлобленному бывшему сотруднику, второму "Я" в абстинентном синдроме, удалить всю информацию и на основном и на резервном сервере. От этого может помочь только ещё одна (и недоступная из интернет!) копия. И желательно инкрементальная, т.е. хранить несколько версий от разных дат. И эта копия не должна храниться в очевидных местах, например дома или на работе. Например багажник машины жены - хорошее место. А поскольку оттуда его могут украсть - разумеется, эта копия должна быть зашифрована.

И мы плавно перешли ко второму аспекту - "недоступность тем, кому не нужно". Имейте в виду, любой винчестер с вашей информацией может попасть в посторонние руки. Вариантов много, это и изъятие милицией "заодно" с соседними серверами, хозяева которых действительно вели незаконную деятельность. И частично вышедший из строя винчестер, который сотрудники Дата-центра вам заменили на новый и отдали в починку, после чего вся информация вновь стала доступна, и другие варианты. Выход - не храните никакую информацию нешифрованой. Для этого существуют различные технологии, например очень хороший вариант - geli-раздел на FreeBSD. Есть аналоги и для других операционных систем. Это создаёт неудобства вроде необходимости вводить пароль при старте, но оно того стоит. Копию в багажнике защитить хотя бы RAR-архивом с паролем.

         И ещё абзац для тех, кто держит корпоративные базы данных в Дата-центре, и не исключает визита "маски-шоу" в свой офис. Оформите договор на размещение серверов в Дата-центре на частное лицо, например сотрудника, которому доверяете. И сам договор не держите на работе. Так серверы будет гораздо сложнее найти.

         Резюмируя: При необходимости в одном сервере, их должно быть 3. Первый основной, размещён в Дата-центре, и, собственно, выполняет всю работу. Второй сервер, размещён в том же Дата-центре, и выполняет роль быстрой замены первому серверу на случай локальных неприятностей. Третий сервер, максимально удаленный географически, является резервом на случай глобальных проблем. А также резервная копия, недоступная из интернета, которая хранится не дома и не на работе. На всех используемых винчестерах информация хранится исключительно в зашифрованном виде. Аппаратная защита на основном сервере: RAID-массив 1 или 10, ну или 5-6, если денег не жаль. В случае, если это корпоративная база данных - договор размещения в Дата-центре необходимо оформлять не на компанию, а на "знакомого друга" и не хранить договор в офисе.

         Исходя из бюджетных ограничений можно пожертвовать вторым сервером (в ущерб скорости восстановления доступности), третий можно арендовать виртуальный (если производительность позволит), и RAID-массив на первом сервере организовать средствами операционной системы, а не аппаратным контролером.

         Разумеется, это не исчерпывающее руководство, и вариантов достижения тех же целей ещё много. Например для обеспечения второго аспекта сохранности можно разнести бекенд и фронтенд по разным Дата-центрам, при этом на дисках фронтенда не хранить ничего, что бы указывало на бекенд, а все необходимые конфигурации вливать на виртуальный диск на фронтенде. Для первого аспекта - разместить десяток копий по всему миру, разбросав посетителей раунд-робином на уровне DNS. Фантазия в данных случаях может быть безграничной. Найдите свою золотую середину.

Последние изменение страницы: 5 мая 2015 г.