воскресенье, 13 мая 2018 г.

Collax V-Bien Office: Статья в немецком журнале IT-Administrator

В апрельском номере журнала IT-Administrator издаваемого в Германии была опубликована статья о тестировании Collax V-Bien Office, специализированного доступного решения виртуализации и высокой доступности для малого бизнеса, сетевых магазинов, частных практик и фрилансеров. Сама статья на немецком языке доступна по ссылке, мы же предлагаем ознакомиться с ее "вольным" переводом.

Автор, Юрген Хейер назвал статью "Kompakter Dauerläufer", что дословно означает "компактный выносливый бегун". Нужно отметить, что идиома "Dauerläufer" немцами чаще употребляется для автомобилей которые пробежали значительно больше и дольше, чем обещали гарантийные обязательства производителя, оставаясь при этом на ходу и не требуя ремонта.  Собственно сама статья:

Компактный выносливый бегун


Даже малые предприятия, сетевые магазины, частные практики и фрилансеры нуждаются в непрерывности и доступности своего центрального сервера. Однако реализация этой задачи часто терпит неудачу из-за высоких затрат, как на аппаратное, так и на программное обеспечение. Collax V-Bien Office позиционирует себя как доступное решение для виртуализации и высокой доступности в очень малых средах. Мы подробно рассмотрели это.

Компания Collax из Мюнхена специализирующаяся на Linux разработках, основываясь на KVM виртуализации, разработала комплексный пакет, который надежно защищает ИТ-инфраструктуру от сбоев и гарантирует, что критически важные приложения всегда доступны. Collax в сотрудничестве с различными поставщиками серверного оборудования предлагает комплексное решение состоящее из двух серверных узлов, программного обеспечения, поддержки и специального запатентованного устройства "Collax Fencing Device". Результатом является доступный и простой в администрировании гиперконвергенный HA(High Availability) кластер по начальной цене значительно ниже 6000 евро. В зависимости от потребностей серверы виртуализации масштабируются в определенных пределах, чтобы удовлетворить потребности малого и среднего бизнеса или фрилансеров, индивидуально.

Запуск в течение нескольких минут

Для нашего тестирования компания Extra Computer GmbH, сотрудничающая с компанией Collax в качестве поставщика оборудования, предоставила нам необходимые серверные узлы. В нашем случае все было подготовлено и настроено компанией Collax, как правило, сбыт осуществляется через специализированных торговых партнеров. Имеются два варианта Поставки: Сертифицированные торговые партнеры получают предустановленные, но не окончательно сконфигурированные узлы, несертифицированные партнеры могут получить уже предварительно настроенный и лицензированный кластер. Последнее мы получили для нашей тестовой лаборатории, перед этим сообщив Collax два свободных IP-адреса из нашей сети, тип сети, шлюз, DNS-сервер и доменное имя. Через три дня системы были поставлены в виде компактного почтового отправления.
Параллельно мы получили по электронной почте инструкции по вводу в эксплуатацию. Наши тестовые системы состояли из двух компактных мини-серверов собственной марки Exone, входящей в линейку Extra Computer. Корпус и системная плата были произведены компанией Supermicro, каждый из которых оснащен процессором Intel d1518 с частотой 2,2 ГГц и четырьмя ядрами, а также 32 Гбайт оперативной памяти. Для хранения данных два из четырех отсеков Hot-Plug были оснащены 2-Тбайтовым жестким диском Toshiba. Диски были подключены к Mega-RAID-контроллеру Broadcom и настроены для работы в зеркальном режиме (Raid 1). Особенностью системной платы является наличие двух сетевых портов 1Гбит/с и двух сетевых портов 10Гбит/с. Дополнительный сетевой порт IPMI обеспечивает прямое управление оборудованием, но не является обязательным требованием. Кроме того, обе системы были оснащены небольшой дополнительной картой, упомянутым устройством Collax Fencing Device, который имеет два внешних порта PS-2.
Подключение оказалась очень простой задачей, в соответствии с инструкцией. Два порта 10Гбит отмечены зелеными и желтыми точками на каждом сервере, их необходимо было соединить друг с другом с помощью соединительных кабелей. Один из двух портов 1Гбит имел синюю точку, каждый сервер был подключен через него к нашей тестовой сети. Оба устройства Collax Fencing Device должны были быть соединены через левый разъем PS-2 (опционально через оба разъема). С этой целью были поставлены два подходящих кабеля PS-2, которые были оснащены специальной защитой от снятия. Подключение монитора или клавиатуры не требовалось, и мы могли включить систему. Нам очень понравилось, что цветная маркировка не представляла никакой проблемы в кратчайшие сроки реализовать подключение без путаницы.
Кстати, V-Bien в зависимости от необходимых аппаратных ресурсов поставляется в трех вариантах, V-Bien OfficeV-Bien и V-Bien ProV-Bien Office предоставляет максимум 4-ядерный процессор и 32 Гбайт оперативной памяти. V-Bien ограничен одним, любым процессором и 64 Гбайт оперативной памяти, а для еще большего объема вычислительных ресурсов потребуется продукт V-Bien Pro с двумя процессорами и 768 Гбайт оперативной памяти на узел.

Умный кластер без кворума

Кабели, описанные в связи с Fencing Device, имеют две цели. Во-первых, это реализация высокодоступного кластера, в соответствии с которым Collax Fencing Device представляет дополнительное двойное соединение, в дополнение к нормальной сети, чтобы иметь возможность обойтись без кворума и избежать ситуации со Split-Brain. Кабель PS2 может иметь длину до 15 метров. Если требуется значительное территориальное разделение  кластера, Stretch-Cluster, есть дополнительный Fencing Expander, который уже использует витую пару и RJ45, что позволяет использовать длину кабеля до 200 метров.

Устройство Fencing Device позволяет использовать метод Stonith (Shoot The other node in The head), чтобы при необходимости надежно отключить узел. Это происходит тогда, когда внезапная ошибка создает опасность возникновения Split-Brain. Связь через соединение осуществляется по протоколу I2C. В наших тестах описанных ниже, мы еще более внимательно рассмотрим Fencing Device.

Вторая цель - реплицировать данные между двумя системами с использованием двух 10-Гигабитных интерфейсов. В дополнение к уже упомянутому серверному зеркалированию диски, созданные для виртуальных машин, синхронно зеркалируются между узлами. Это позволяет виртуальным машинам быстро мигрировать между серверами во время работы. В случае внезапного сбоя узла результирующие неработающие виртуальные машины могут быть перезапущены немедленно и без потери данных на оставшейся системе.

Интуитивно понятное администрирование кластера

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

Веб-интерфейс V-Bien нам понравился своей наглядностью и интуитивно понятным интерфейсом. Панель мониторинга дает хороший обзор состояния системы (высокая доступность, текущие сигналы тревоги), уровня загрузки системы в виде использования системы и дискового пространства. Администратор с первого взгляда видит, сколько виртуальных машин создано и сколько работает. При нажатии на одно из окон открывается подробное описание состояния выбранного параметра. Новые виртуальные машины можно создавать непосредственно из панели мониторинга. В нормальном режиме виртуальные машины распределяются между двумя узлами автоматически, при желании ИТ-специалист может дополнительно указать для каждой виртуальной машины, какой узел должен быть предпочтительным. При создании виртуальных машин необходимо убедиться, что каждый узел занят только наполовину, чтобы в случае сбоя одного узла было достаточно ресурсов, оставшихся для работы. Более высокая нагрузка на оба узла, конечно, возможна, только в случае сбоя одного из узлов, администратору может потребоваться оставить отдельные виртуальные машины в выключенном состоянии, до восстановления кластера.

Несмотря на то, что виртуализация основана на KVM, администратору не требуются знания  Linux, все управляться с помощью графического интерфейса. Администратор должен только освоить работу интерфейса. Для тестирования мы создали виртуальную машину с Windows Server 2016 и выполнили необходимые действия. Обратите внимание, что установочные образы(ISO-образ) операционной системы следует предварительно скопировать или импортировать в кластер с помощью графического интерфейса пользователя. После установки виртуальной машины не возникло никаких проблем. Доступ к графическому интерфейсу виртуальной машины может осуществляться через RDP или VNC Viewer. В случае с RDP предоставляется не прямой доступ к виртуальной машине, сервер RDP установлен в кластере и предоставляет весь список запущенных виртуальных машин с RDP консолью. При этом администратор должен ввести пароль, а затем увидеть список всех запущенных виртуальных машин, чтобы выбрать нужную. 

Мониторинг, резервное копирование данных и интеграция с источником бесперебойного питания

V-Bien Office поставляется с встроенной системой мониторинга - Nagios. При нажатии на кнопку Мониторинг в меню появляется окно с тремя древовидными разделами "мониторинг", "отчетность" и "конфигурация". Здесь можно посмотреть информацию о запущенных службах и отслеживаемых хостах с историей последних сообщений. Если SMTP-почта настроена, система также отправляет уведомления по электронной почте.

В рамках отчетности, мониторинг предоставляет информацию о тенденциях, доступности и событиях. Администратор может загружать системные журналы и получать статистические данные об использовании центрального процессора, ОЗУ, сети для хостов и виртуальных машин. Период отчета может составлять от четырех часов до целого года.

При дальнейшем изучении меню V-Bien, разделенного на три части "службы виртуализации", "инфраструктура" и "состояние/обслуживание", мы обнаружили, наряду с описанным мониторингом, некоторые полезные дополнительные функции, такие как интегрированное резервное копирование данных. Вручную или по расписанию администратор может выполнять резервное копирование виртуальных машин на внешний общий ресурс. Для этого нужно создать задание резервного копирования и выбрать место назначения резервного копирования. Чтобы создать место назначения резервного копирования, укажите целевой сервер в меню "Hosts" (хосты). V-Bien Office понимает под узлами не только два узла кластера, но и зарегистрированные DNS-сервер, NTP-сервер, маршрутизатор и SMTP-сервер. В нашей конфигурации было семь хостов. Администратор при установке целевого сервера, может указать, является ли целевой сервер общим ресурсом CIFS/SMB или NFS, а также указать путь и учетные данные.

В тесте мы указали место назначения резервного копирования на сервере Windows, произвели резервное копирование виртуальной машины, а затем восстановили ее под другими именами. Во время восстановления мы могли указывать, следует ли V-Bien перезаписать существующую виртуальную машину или нужно создать новую с другим именем. Мы выбрали последний вариант и запустили виртуальную машину после восстановления, что без проблем отработало. Еще одной особенностью является возможность интеграции с источником бесперебойного питания для контроля перебоев в электроснабжении. Непосредственно из графического интерфейса можно также получить доступ к документации. 

Только минимальное время простоя в случае сбоя системы

Ранее мы описали, что кластер V-Bien отключает один из двух узлов для обеспечения безопасности в случае внезапного отказа избежать ситуации с Split-Brain. Мы хотели более четко видеть, как кластер реагирует в разных ситуациях сбоя. Для этого мы подключили его полностью, включая соединение с Fencing Device. Мы отключаем отдельные соединения в обратном порядке и ждали между ними несколько минут, чтобы дать время системе мониторинга для формирования сообщений или предупреждений. С одной стороны, сообщеня были видны на приборной панели, с другой стороны, уведомления отправляются по электронной почте.

Для первой попытки мы отключили соединение 10Гбит, что привело к предупреждению с уведомлением по электронной почте. Состояние кластера изменилось на желтый. При отключении второго соединения состояние поменялось на красный, а через несколько секунд узел был отключен. Текущие виртуальные машины были перезапущены на оставшемся узле, но в этом случае миграция в реальном времени перед отключением не состоялась. После повторного подключения отключенных портов мы смогли снова включить и активировать узел. Кластер полностью синхронизировался и через некоторое время снова стал зеленым. Предполагается расширить функцию Proactive-HA в рамках будущих обновлений таким образом, чтобы частичный сбой подключения уже приводил к динамической миграции виртуальных машин для предварительной эвакуации узла, предназначенного для отключения.

В последующей, второй попытке мы сначала сняли один из двух кабелей Fencing Device. Это не привело к сообщению или предупреждению. После вычитания второго соединения появилось соответствующее сообщение, состояние кластера изменилось на красный. Далее мы отсоединили 10-гигабитное соединение и через некоторое время второе. Оба узла теперь были
подключены только к клиентской сети. В этой ситуации ни один из двух узлов не был автоматически отключен, оба продолжали работать, включая активные виртуальные машины, но администрирование виртуальных машин больше не было доступно через графический интерфейс. Чтобы решить эту проблему, мы вернули все соединения. Интересно, что кластер не синхронизировался снова самостоятельно. Скорее, у нас создалось впечатление, что узлы блокируют друг друга посредством текущих проверок. После того, как этот статус не менялся в течение нескольких минут, мы решили отключить один из двух узлов и начать снова. Это в конечном итоге привело к результату. Выключенные виртуальные машины были запущены на другом узле, подключенный к нему узел находился в режиме обслуживания. Теперь мы смогли активировать узел, данные были синхронизированы, а через некоторое время у нас снова появился кластер HA в зеленом состоянии. После консультации, производитель подтвердил это поведение. Многочисленные ошибки, которые мы спровоцировали, должны быть сознательно устранены квалифицированным персоналом, либо администратором, либо поддержкой Collax. В небезопасных ситуациях, рекомендуется связаться с поддержкой, прежде чем это может привести к потере данных.

С третьей попытки мы отключили патч-кабель к клиентской сети на хосте. Через несколько минут состояние кластера изменилось на красный. Ни одна из виртуальных машин, распределенных между двумя узлами, не была перенесена, но виртуальные машины на отключенном хосте были недоступны в клиентской сети.  Сетевой трафик не был перенаправлен в сеть клиента через оставшийся порт на другом хосте. Нам пришлось вручную перенести виртуальные машины, чтобы они могли быть доступны с другого хоста. Тем не менее, это можно сделать, подключив оставшийся порт GBit на хостах к клиентской сети, чтобы между этими двумя портами мог произойти переход на другой ресурс. В этой связи Collax сказал нам, что маршрутизация по другому хосту реализована и может быть активирована по запросу со стороны поддержки.

Профилактическая миграция с помощью Proactive HA

В дополнение к описанному Fencing Device, V-Bien в течение уже некоторого времени предлагает еще одну интересную дополнительную функцию под названием "Proactive HA". Fencing реагирует на спонтанные сбои строго путем отключения узла и при этом перезапуская виртуалные машины на другом узле. Proactive HA обрабатывает ситуации, в которых аппаратные сбои происходят раньше, например ошибки в памяти или на одном из жестких дисков. Для этого программные датчики регулярно контролируют оборудование и перемещают виртуальные машины на неповрежденный узел при первых признаках ошибки. Затем проблемный хост удаляется из кластера и оповещается администратор.

В заключение, мы обнаружили, что концепция Fencing Device. хорошо работает, чтобы избежать ситуации со Split-Brain. Тем не менее, V-Bien Office не пытается (пока) переместить виртуальные машины заранее, когда возникает ситуация, требующая остановки узла. Proactive HA обещает лучшее поведение в будущем. В дополнение к мониторингу датчиков для обнаружения надвигающейся проблемы в узле эта функция в скором времени также позволит перенести запущенные виртуальные машины и прерванные сетевые соединения до выключения узла для обеспечения бесперебойной доступности. Однако на сегодня при так называемых двойных отказах, которые мы спровоцировали в тесте, V-Bien Office бессилен и  требует ручного вмешательства. Однако это относится и к другим решениям высокой доступности на рынке.

Вывод

В тесте V-Bien Office убедительно показал себя себя в качестве полноценной виртуализации по доступной цене. Вполне достаточно реализованы поддержки  актуальных операционных систем, включает последние версии Windows и различные дистрибутивы Linux, придавая V-Bien универсальность. В дополнение к варианту Office, Collax имеет в портфеле V-Bien и V-Bien Pro, чтобы предложить многоуровневые решения для различных требований.

Collax V-Bien Office является очень интересным выбором для малого и среднего бизнеса и фрилансеров, если вы ищете готовое полное решение для виртуализации и высокой доступности. Спроектированное на основе надежных стандартных компонентов, таких как Supermicro, использующие недорогие серверные системы различных поставщиков. С точки зрения необходимых вычислительных ресурсов, предлагаются системы с различными ресурсами процессора и памяти. обратите внимание, что Collax V-Bien ограничен одним кластером высокой доступности с двумя узлами. Три варианта V-Bien OfficeV-Bien и V-Bien Pro, которые позволяют использовать серверное оборудование различной мощности, Collax связывает стоимость лицензии с возможностями вычислительной среды. К счастью, число виртуальных Машин ни в коем случае не ограничено.

Виртуализация с V-Bien основана на KVM, что ограничивает затраты. Возможность предварительно сконфигурировать полный пакет помогает снизить затраты на настройку. Ввод в эксплуатацию требует мало опыта, что дает возможность для покупателя обойтись своими силами.

Различные тесты отказов показали, что кластер высокой доступности с различными сценариями отказов вполне оправдывает себя, реагируя на фенсинговые события в спонтанных сбоях, отключая сбойный хост и перезапуская текущие виртуальные машины на оставшемся хосте. В случае медленно возникающих проблем,, Proactive HA автоматически переносит виртуальные машины перед отключением. Однако в случае нескольких одновременных сбоев соединения могут возникнуть ситуации, в которых требуется вмешательство вручную.

понедельник, 7 мая 2018 г.

О Малом и Среднем.. ИТ-ландшафт

 Скорость с которой в современном мире развиваются информационные технологии и восхищает и пугает одновременно. Пугает именно тем, что по прошествии времени все это могут назвать "самой большой технологической авантюрой".  Бешеный рост числа ИТ-компаний создающих новые технологии и разрабатывающих новые информационные решения с одной стороны и еще больший рост "Облачных" компаний предоставляющих, выше названным ИТ-компаниям, виртуальные инфраструктуры и сервиса. "Спрос рождает..."(с), но это очень похоже на "бег по кругу" когда у ИТ-компаний занимающихся сложными интеллектуально емкими решениями, в том числе и в области информационной безопасности или финансовых технологий, полностью отсутствует своя ИТ-инфраструктура, точнее она есть в минимальном варианте доступа к сети интернет, а все остальное находится в облаках, да еще и за пределами РФ. Риски!? Среди неявных рисков: риск потери квалификации, когда сотрудники теряют представление и навыки эксплуатации решений в реальной, а не виртуальной инфраструктуре заказчика.  Проверьте сами, например последние 1,5-2 года я всегда проверяю электронную почту моих респондентов на наличие собственного MTA. А у кого из них есть собственный корпоративный мессенжер?

Возвращаясь к теме ради которой этот пост и задумывался:

ИТ-ландшафт для малого и среднего бизнеса.
На наш взгляд эта картинка максимально раскрывает состояние дел в теме ландшафта. Не секрет, что многие молодые проекты начинают в облаках(AWS, Google Cloud, etc) и наслаждаются ИТ-инфраструктурой которая "доставляет" как ромашковое поле :) И опять-же не секрет, что проблемы порожденные регуляторами(РКН) "накрывают" это ромашковое поле вполне просматриваемым ландшафтом.

Проект Collax.ME, как и положено oldschool-ным специалистам, рекомендует сменить парадигму архитектуры ИТ-инфраструктуры в сторону локального частного облака, однако не исключая взаимодействия с публичными облачными инфраструктурными сервисами. Что для этого нужно? В минимуме - пара каналов интернет от разных провайдеров, пара серверов и носитель для бэкапов. Что в итого получается:
1. Балансировка каналов связи и их фаерволинг, управление внутренними виртуальными сетями, локальные первичные/вторичные или и те и другие DNS, управление учетными записями и правами доступа и т.д.
2. Локальные средства групповой работы с единым интерфейсом и интеграцией с привычными офисными приложениями: почта + файловый обмен + мессенжер c видеоконференцими
3. Высокодоступное и отказоустойчивое решение для бухгалтерии, например 1С, и/или для систем класса CRM
4. Простая и эффективная система резервного копирования, где скорость восстановления определяется скоростью чтения с носителя.
5. Простор для локальной разработки(DevOps) cо всеми плюшками как и в публичных облаках, с возможностью легко переносить контейнеры и имиджи в публичные облачные инфраструктуры.
Про DevOps... добавим кусочек описания нашего ландшафта, проверенного и обкатанного до автоматизма. Зона наших интересов крутится вокруг Docker и разработки на языке Golang. Естественно мы поддерживаем Kubernetes и в тоже время используем Swarm. Для наглядности и управления контейнерами в Swarm кластере мы используем Portainer.IO или консольный Dry. Для K8s мы используем разработки компании Rancher Labs. Все это живет в нашем кластере на Collax V-Cube+  в виде KVM имиджей, управляется через веб-интерфейс или из командной строки аналогично docker-machine.