OpenSVC только что был перенесен на платформу FreeBSD. Небольшая аннотация в этом объявлении заинтриговала меня, поэтому я пошел в Веб-сайт OpenSVC и нашел это:
OpenSVC - это «диспетчер служб», как и диспетчер кластерных служб, разработанный для реальных гетерогенных центров обработки данных и оркестратор крупномасштабных операций (например, аварийное восстановление).
Службы - это наборы ресурсов (виртуальная машина, IP-адрес, группы дисков, файловые системы, синхронизации файлов и средства запуска приложений).
Службы можно запускать, останавливать и запрашивать состояние, обеспечивая согласованный набор команд для совершенно разных типов интеграции служб.
Конфигурации служб, состояние и журналы отправляются в центральную базу данных, соединенную с веб-интерфейсом (сборщиком).
Службы можно администрировать с помощью автономного программного стека GPLv2, развернутого на узлах (nodeware), или через веб-интерфейс.
Плюс немного графики в стиле UML. Это все здорово, но я все еще не понимаю: что он делает? Я просто тупица? Какой вариант использования этой системы?
Я попытаюсь описать конкретные случаи, чтобы объяснить полезность OpenSVC.
Рассмотрим системного администратора в корпорации, который настраивает службы для клиентов / пользователей. В его ведении около 50 служб. Ему нравится FreeBSD, поэтому он обычно развертывает свои сервисы на этой базе. Он хорошо разбирается в том, как работает rsnapshot, поэтому он создал сценарии для автоматизации резервного копирования и тщательно подготовленные сценарии, помогающие восстановиться после сбоя сервера, а может быть, даже после отключения сайта.
Системный администратор в следующем кабинете также отвечает примерно за 50 других служб. Он тоже сделает свою домашнюю работу правильно, но в своем собственном стиле. Он может предпочесть Linux и rsync, его сценарии восстановления будут в другом месте (возможно, на его рабочем столе). Его клиентам может потребоваться большая доступность, поэтому ему пришлось выбрать стек кластеризации.
Теперь масштабирование до десятков администраторов и тысяч сервисов. Центр обработки данных представляет собой лоскутное одеяло технологий: от 3 до 4 различных операционных систем, 2 различных оборудования для хранения данных с собственным протоколом репликации (hitachi shadow copy, emc srdf, netapp snapmirror), 2 стека кластеризации (hacmp, redhat cluster, suncluster, veritas cluster), множество различных скриптов для автоматизации действий на небольших периметрах.
И представьте некоторые частые сценарии: o утечка через стойку: 20 серверов не работают, 50 сервисов нуждаются в аварийном переключении, 10 разных администраторов со всеми их специфическими механизмами аварийного переключения o отключение сайта: тот же эскиз, в десять раз o корпорация передала на аутсорсинг мониторинг сервисов: Трудно доверять низкопрофильному скринеру с тонко настроенными службами, ответственность за запуск / остановка действий o переход системных администраторов: всю тонкую настройку нелегко передать новичку.
OpenSVC можно рассматривать как бесплатный, простой в развертывании кластерный стек, который можно развернуть повсюду. У служб с низкой критичностью может быть только один узел. Сервисы со средней степенью критичности могут иметь 2 узла и не иметь автоматического переключения при отказе. Услуги с высокой критичностью, 2+ узла с автоматическим переключением при отказе плюс удаленный узел для аварийного восстановления.
Один и тот же инструмент для всех, соблюдая все предпочтения системных администраторов (операционная система, модель виртуализации, файловая система, схема репликации) и все цели доступности для обеспечения действий остановки / запуска / репликации для таких различных типов интеграции.
Я сфокусировал этот пример на крупномасштабной среде, чтобы подчеркнуть полезность OpenSVC, но в реальной жизни многие пользователи используют OpenSVC для управления от 1 до 4 сервисов, просто чтобы выпустить множество скриптов, которые они поддерживали сами ранее.
Веб-сборщик дает дополнительные преимущества в качестве интерфейса для создания отчетов, предупреждений и интеллектуального анализа данных. Этот компонент не распространяется под лицензией GPL, но он не нужен, чтобы извлечь выгоду из вышесказанного. Внештатные сотрудники, как правило, используют интернет-коллектор, чтобы иметь единую точку отчетности по услугам, которые они поддерживают для разных клиентов.
Надеюсь, это поможет прояснить позицию OpenSVC в мире кластеризации.
Похоже, это агрегатор статуса сервисов на кластере машин в центре обработки данных. Может быть, это центральное место для мониторинга ваших файловых серверов, веб-серверов, серверов NFS, виртуальных машин и т. Д., А также журналов состояния и прочего.
Кроме того, похоже, что вы можете перезапускать службы, останавливать их, "пинговать" их и т. Д. В основном инструмент, помогающий контролировать и контролировать множество компьютеров в центре обработки данных из одного места.
Есть несколько менеджеров кластерных сервисов для высокая доступность Linux. (Хотя у меня нет других удобных ссылок) Это похоже на предложение FreeBSD для управления ресурсами в настройках кластера (т.е. убедитесь, что веб-сервер доступен по крайней мере на 1 из узлов кластера @ все время, и т.д)