Внешние архитекторы разработали архитектуру для среды сервис-ориентированной архитектуры. Они установили, что доступность составляет 99,9%, что эквивалентно максимальному времени простоя в 9 часов [в год].
Где я могу найти ресурсы по как сопоставить это с физической архитектурой?
Основными компонентами, которые, как мы думаем, нам пока необходимы, являются:
Drupal CMS со своей базой данных (одна машина)
API: авторизация, аутентификация, ведение журнала, управление, PubSub и хранилище обучающих записей LRS: (один сервер приложений)
Один сервер базы данных для хранения (LRS, журналы, профили)
Это для муниципальной среды города с 5 миллионами душ. Нет данных о требованиях к параллельному доступу и тому подобному, но я бы не стал особо разбираться в этом вопросе. Стратегия заключается в том, чтобы начать экономно, но надежно и при необходимости расширяться.
Пожалуйста, вы можете запросить дополнительную информацию или прокомментировать первый снимок компонентной архитектуры - или все, что вы сочтете уместным. Спасибо.
Перед проектированием какой-либо архитектуры я бы проверил вашу среду: есть ли у вас внутренний ИТ-отдел и что в нем размещается?
Если сервер базы данных уже установлен, он также может разместить вашу базу данных.
С чем знакомы ваши системные администраторы? Если ваш магазин Microsoft, решение, основанное на любом * nix, может легко расстроить ваших администраторов (или наоборот)
Что касается времени простоя, все ли вовлеченные стороны согласны с тем, что время простоя в девять часов учитывается только для незапланированный время простоя и не делать не включать время простоя для установки исправлений и обновлений? Сколько данных нужно восстановить? Можно ли восстановить всю систему в течение девяти часов с помощью системы резервного копирования?
Я делаю высокодоступный Drupal, зарабатывая на жизнь инженером в BlackMesh. Как сказал TomTom, все, что составляет 99,9% («три девятки») и ниже, очень просто.
Получить более 99,9% легко, если вы хотите потратить деньги на добавление серверов, балансировщиков нагрузки и тому подобное. Если вы этого не сделаете, может быть другой выход. Я бы переделал ваше решение в виде двух машин и потратил сэкономленные от отсутствия третьей машины деньги на то, чтобы сделать две другие более мощными. Возможно, что противоречит интуиции, вы также можете серьезно подумать о том, чтобы пожертвовать некоторым уровнем избыточности, например, вы можете отказаться от вторичного источника питания на физической машине в пользу простого подключения каждой из этих двух машин к разным шинам.
В любом случае, что вы делаете с этими двумя машинами, вы настраиваете их в соответствующий кластер. Иметь IP-адреса высокой доступности, которые не работают между ними. * Первая машина - это веб-машина по умолчанию, на которой запущен Drupal. Вторая машина - это машина DB и LRS по умолчанию. В случае сбоя адреса перемещаются так, что оставшаяся машина принимает на себя полную нагрузку. Для MySQL это потребует репликации мастер-мастер; для Drupal потребуется синхронизация DocRoot (обращая особое внимание на каталог "files"); для вашей LRS это может потребовать ручного переключения при отказе.
При таком типе конфигурации, с приличным оборудованием, хорошей мощностью и т. Д. Вы должны ожидать увидеть пять девяток (99,999%) времени безотказной работы ОС (что соответствует примерно пяти минутам простоя в год), и близко к этому числу в условия доступности уровня 7. Поскольку вы сказали, что вам нужно обосновать полученные числа, пять девяток предполагают среду без совместного использования ресурсов и представляют собой просто частоту отказов отдельного сервера (1.0-99.75%==0.25%) в квадрате, чтобы представить вероятность одновременного отключения двух серверов (1.0-0.25%*0.25%==99.999375%), с небольшой ошибкой.
Наконец, я должен отметить, что такого рода SLA - отвлекающий маневр. Видеть https://serverfault.com/a/161141/46760 за мои мысли по этому поводу. Реальность такова, что вы потеряете ДНЕЙ функциональной доступности из-за того, что кто-то щелкнет по учетной записи администратора Drupal (или что-то подобное) в течение срока действия этого решения. Для настройки хорошего контроля изменений и аналогичных процессов следует предоставить равные, если не первые, выставления счетов, а не обсуждение избыточности оборудования.
*: n.b. В любом кластере с четным числом членов есть вероятность раздвоения мозга. Один из лучших способов снизить вероятность - направить трафик проверки работоспособности через общедоступные интерфейсы. Если вы хотите быть действительно параноиком, посмотрите на STONITH, а не на сериал.
99.5 довольно (чрезвычайно) дрянный и простой в использовании - помните, что единственная машина имеет время безотказной работы 99,9%, поэтому технически вам просто нужно иметь отдельный сервер, конфигурацию на месте, резервное копирование каждые пару минут.
При правильной настройке вы сможете запустить резервную машину максимум за 10 минут.
Это обрабатывает все, кроме сбоев центра обработки данных, но это уровень SLA, и тогда вы можете иметь что-то вроде azure / amazon со вторым компьютером во втором центре обработки данных.