Ставим несколько нод на 1 сервер
Первая статья за этот год. Собрал небольшой полезный материал для вас.
-
Несколько нод на 1 сервере. Проверка нагрузки на сервер. Проверка портов.
Несколько нод на 1 сервер
Для оптимизации расходов можно ставить 2 и более нод на 1 сервер. Главное помнить некоторые моменты:
-
Проекты с 1 сетью часто конфликтуют, поэтому лучше ставить ноды разных сетей на 1 сервер; Нагрузка на сервер; Порты.
Плюсы и минусы разбирать не будем, хотя есть уточнение — при 100% нагрузке CPU сервер будет перезагружаться, поэтому важно следить на нагрузками.
Проверка нагрузки на сервер
Проверить нагрузку на сервер можно двумя способами — через Grafana или с самого сервера.
Grafana — пользуюсь на протяжении нескольких месяцев, показывает общий дашборд, удобно следить за нагрузками на сервер.
Небольшой минус — нужен отдельный сервер под ноду-обработчик (1 Core x 1 GB RAM).
Несколько Tendermint нод на одном сервере
⠀О том, как можно запустить несколько нод, использующих Tendermint (например OmniFlix, Stratos, Findora и пр.), написано в этой статье.
Содержание
Кратко о Tendermint
⠀Tendermint — это алгоритм консенсуса, устойчивый к злоумышленным действиям. Алгоритм был придуман в 2014 году Джае Квоном, который был озабочен проблемой высокого энергопотребления сети Bitcoin’а. В отличие от Nakamoto консенсуса, где выбирается цепочка с наибольшей совокупностью сложности, в Tendermint выбирается цепочка, где за блок проголосовало 2/3 участников сети.
-
Прост в понимании; Довольно быстрый; Блок не может быть отменен после того, как 2/3 проголосовало и подтвердило его.
-
Если нода, которая должна создать блок, его не создает, то необходимо подождать некоторое время до начала нового раунда; Алгоритм плохо масштабируется так как за каждый блок должно проголосовать 2/3 сети.
Решение конфликта
⠀Для решения проблемы необходимо изменить используемые порты в конфиге
Автоматическое
⠀Подойдёт, если на сервере стоит 2 ноды
1) Перейти в директорию с файлом config.toml или изменить путь файла в команде и использовать её
2) Перезапустить ноду командой
Ручное
1) Найти файл config.toml нужной ноды (обычно находится в директории DIR_WITH_NODE/config/ )
2) Открыть его с помощью текстового редактора и найти строки, показанные ниже
И строку pprof_laddr = "localhost:6060"
3) Заменить порты, чтобы не было пересечения со стандартным конфигом
4) Сохранить config.toml
5) Найти файл app.toml (обычно находится в директории DIR_WITH_NODE/config/ )
6) Открыть его с помощью текстового редактора и найти строки, показанные ниже
Несколько нод, использующих Tendermint, на одном сервере
О том, как можно запустить несколько нод, использующих Tendermint (например OmniFlix, Stratos, Findora и пр.), написано в этой статье.
Содержание
- Кратко о Tendermint
- Решение конфликта
- Автоматическое
- Ручное
- Небольшие трудности
- Полезные ссылки
- Благодарности
Кратко о Tendermint
⠀Tendermint — это алгоритм консенсуса, устойчивый к злоумышленным действиям. Алгоритм был придуман в 2014 году Джае Квоном, который был озабочен проблемой высокого энергопотребления сети Bitcoin’а. В отличие от Nakamoto консенсуса, где выбирается цепочка с наибольшей совокупностью сложности, в Tendermint выбирается цепочка, где за блок проголосовало 2/3 участников сети.
- Прост в понимании;
- Довольно быстрый;
- Блок не может быть отменен после того, как 2/3 проголосовало и подтвердило его.
- Если нода, которая должна создать блок, его не создает, то необходимо подождать некоторое время до начала нового раунда;
- Алгоритм плохо масштабируется так как за каждый блок должно проголосовать 2/3 сети.
Решение конфликта
⠀Для решения проблемы необходимо изменить используемые порты в конфиге
Автоматическое
⠀Подойдёт, если на сервере стоит 2 ноды
1) Перейти в директорию с файлом config.toml или изменить путь файла в команде и использовать её
2) Перезапустить ноду командой
Ручное
1) Найти файл config.toml нужной ноды (обычно находится в директории DIR_WITH_NODE/config/ )
2) Открыть его с помощью текстового редактора и найти строки, показанные ниже
Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке
Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер hyper-v. Однако времена были давние, еще до выхода 2012 сервера. Для организации кластера требуется внешнее хранилище и сделать отказоустойчивость из двух серверов было в принципе невозможно.
Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.
Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.
Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.
Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.
Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Поддерживаются NVMe, SATA, SAS. Работа с дисками через RAID контроллеры не поддерживается. Более подробно о требованиях docs.microsoft.com
Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Подробнее по ссылке.
Поэтому я создал две виртуальные машины – node1, node2 и сразу отключил динамическую память. Затем необходимо включить поддержку вложенной виртуализации:
Включаем поддержку спуфинга на сетевых адаптерах ВМ:
HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.
Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.
Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты sconfig это не составит большого труда. Уточню только, что установил Windows Admin Center с помощью скрипта:
По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.
Когда подготовительная часть готова и перед тем, как приступать к созданию кластера, рекомендую обновить ноды, поскольку без апрельских обновлений Windows Admin Center не сможет управлять кластером.
Приступим к созданию кластера. Напомню, что все необходимые консоли у меня установлены на контролере домена. Поэтому я подключаюсь к домену и запускаю Powershell ISE под администратором. Затем устанавливаю на ноды необходимые роли для построения кластера с помощью скрипта:
И перегружаю сервера после установки.
Запускаем тест для проверки готовности нод:
Отчёт в фомате html сформировался в папке C:\Users\Administrator\AppData\Local\Temp. Путь к отчету утилита пишет, только если есть ошибки.
Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100
После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.
И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.
Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том. Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB.
На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.
Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.
Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager.
Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center. Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик
Подключимся к одной из нод и выполним скрипт:
Проверяем Admin Center и на этот раз получаем красивые графики
После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.
И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. Тут стоит вернуться к аппаратным требованиям. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.
Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 . Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют.
В заключении хотел бы сказать несколько слов о своих впечатлениях. Знакомство с новыми технологиями это был для меня весьма интересный опыт. Назвать его полезным, пока не могу. Я не уверен, что смогу применить эти навыки на практике. Поэтому у меня вопросы к сообществу: готовы ли вы рассматривать переход на гиперконвергентные решения в будущем? как относитесь к размещению виртуальных контроллеров домена на самих нодах?