Carding 4 Carders
Professional
Всем привет) Для тех кто в теме и для информации всем. Решил поделится опытом и возможно его приобрести с помощью данной темы. Долго это все продумывалось. Сегодня на первых так сказать парах, запустил в тестовом режиме вот такой вариант.
Для тех кто еще ничего не понял, но очень хочет) Следующее фото:
На данный момент, мы видим материнскую плату погруженную в трансформаторное масло вместе с блоком питания и всеми необходимыми элементами для полноценного запуска системы. Если вы видите индикатор зеленого цвета, то можете понять что сейчас мать включена и работает без проблем) Масло с помощью циркуляционного насоса прогоняется через систему охлаждения, она же батарея) Тем самым охлаждает жидкость в бочке. На процах висит по радиатору и никаких кулеров. Напомню это тестовый вариант. Вообще в планах на ближайшие дни, поднять железо, которое будет стоять вот в этой компактной
емкости.
Кстати масло уже приобрел и оно ожидает своего часа)
Что хочу что бы получилось в итоге. Для тех кто понимает о чем идет речь и шарит в отрасли серверного оборудования и его настройки.
Сервер на котором находятся все данные (на картинке SRV12R2-STOR).
к нему через infiniband подключены сервера без дисков (ноды) на которых будут работать виртуалки.
В общем вот такое интересное дело. В тему буду кидать новости о продвижении, если конечно будет актуально для кого-то.
Емкость закрытая, поскольку масло имеет запах и оно гигроскопично. Масло на первых фото почти не имеет резкого запаха, его почти не слышно. А вот перед этим, было другое масло, оно воняло ппц. В помещении долго находится было очень тяжело) Вот кстати тест первого запуска с маслом. С тем которое воняло.
Масло трансформаторное Т-1500 сернокислотной и селективной очисток, вырабатываемое из малосернистых нефтей. Применяются для масляных выключателей и другой высоковольтной аппаратуры (напряжением до 500 кВ) в качестве основного электроизоляционного материала. Оно не простое)) Это масло тоже из авто-магазина,, моторное масло не подойдет.
Вот еще по маслу: "Трансформаторные масла́ — минеральные масла высокой чистоты и низкой вязкости. Применяются для заливки силовых и измерительных трансформаторов, реакторного оборудования, а также масляных выключателей. Предназначено для изоляции находящихся под напряжением частей и узлов силового трансформатора, отвода тепла от нагревающихся при работе трансформатора частей, а также предохранения изоляции от увлажнения."
Сейчас вот готовлю к погружению.
Это спаренные IBM БП 12V 49A (12V 98A, 1.2kW)
Тут 4 Xeon X5570 96гб ОЗУ.
Продолжаем)
Нам нужно получить:
1. отказоустойчивый кластер
2. возможность увеличения мощности путем добавления железа
3. возможность управлять всем удаленно
4. максимально эффективная система охлаждения
5. максимально эффективная система основного питания
6. максимально эффективная система резервного питания
7. максимальная плотность размещения серверов
8. максимально минимальная цена (в рамках разумного)
Так как сервера которые есть выводить из эксплуатации пока нельзя, придется покупать новые железяки и их должно хватить на организацию кластера и свободных ресурсов кластера по итогу должно быть не меньше чем у минимального сервера который в данный момент работает (что бы по очереди всех существующих клиентов пересадить на кластер, а сервера добавить как узлы (ноды) кластера)
Система охлаждения.
Воздушную систему охлаждения эффективной особо не назовешь, нужно что-то другое, как вариант трансформаторное масло.
Плюсы:
· достаточно эффективная система потому что полностью равномерное отведение тепла (включая те места где воздухом не охлаждается или плохо охлаждается )
· из-за равномерного отвода тепла — компоненты матери проживут дольше
· из-за большей теплоемкости масла - нет резких перепадов температуры в охлаждении
· снижается расход электричества, за счет отсутствия куллеров
· решается проблема с статикой и вихревыми токами
· тепло получаем не в виде горячего воздуха в серверной, а в жидком виде.
· тепло в жидком виде можно дальше использовать как вздумается (куда его девать придумаем потом, пока зима — оно и в офисе не помешает)
· тишина!!!
Минусы
· все в масле (не самые приятные ощущения + постоянно руки мыть нужно), но пережить можно ))
· если вдруг что-то случится с системой охлаждения, масло дотечет до подвала ( > 200литров, 4 этажа вниз) и будут проблемы с собственником здания
Так как мы хотим все быстрее, пока основную систему не доделали и не запустили, используем батарею отопления + насос + емкость для погрузки железяк. С охлаждением +/- разобрались, дальше нужно железо которое будет работать. Покупаем серверные материнские платы + процы + ОЗУ, все без корпусов, так значительно дешевле и они все равно не нужны
Источник питания мат плат.
Для максимальной эффективности этого момента, нужно еще думать о резервном питании. В инструкции к матерям написано что им для работы нужно +12 (основной) +5 (дежурка) и контакт который мать замыкает на массу для запуска блока питания. В целом все ясно, у нас были 2 блока питания с сервера IBM, в сумме они 1,2 кВт (два по 600 Вт) но у нас на старте 4 матери, нужно или 4 блока питания или думать что-то еще. Выбираем второй вариант, блоки питания в будущем нам все равно не нужны будут, потому их покупать смысла нет. Берем герконовое реле + автомобильное реле (с фар), масса от матери включает герконовое реле которое включает автомобильное. Получили независимое от блока питания отключение/включение материнских плат, нужно только обеспечить дежуркой ( +5 ), оно есть на блоках питания.
Включаем параллельно блоки питания, получаем 1,2 кВт блок питания, матери в полной комплектации предельно потребляют около 400Вт, блока питания для 4х матерей хватит + они не в полной комплектации, хватает с избытком.
Предоставлять ничего не собираюсь, пока) Все что есть, работает и загружено по максимуму, 24/7. Тему создал для того что бы поделиться опытом с людьми которые занимаются серверным оборудованием. Может у кого-то из клуба есть свои серваки, а они даже не задумывались о таком решении. Так же может кто-то уже реализовал данный метод и поделится опытом)))
Железяка была погружена в масло, успешно запущена и находится в процессе настройки.
Температурный режим:
В помещении +18 °С, с данной системой охлаждения, 50 литров масла, на каждой мамке стоит по системе, в режиме простоя +46 °С
Да была такая проблема, до того момента пока не подписал договор с двумя самыми крупными провайдерами в городе на уровень обслуживания 99,9%, это конечно не пять девяток, но пока что есть, альтернативы пока все равно нет, в будущем придумаю как добавить еще каналов.
С другой стороны: 88 часов простоя в год, да плохо, но это все равно уже лучше чем 1 канал и без SLA
Кроме того, система охлаждения 1U сервера основана на 6-8 ми спаренных кулерах по 14- 20-ти ват на каждый. И поверьте они (куллеры) не простаивают. А это минимум 50-60 Вт. при простое сервера, и под 100 Вт при полной нагрузке. (при потреблении самого железа около 300-350 Вт.).
То есть около 30% энергии тратится при охлаждении в пустую. В принципе это само по себе не страшно, но потом это тепло утилизируется кондиционером с еще 30-40 %-ми затрат.
Это все тоже не так страшно, пока мы не доходим до пункта охлаждения и бесперебойного питания в целом. При мощности оборудования 3кВт (сама электроника будет потреблять 2,4 кВт и 0,6 кВт куллеры) потребуется 2 кондиционера мощн. по 1кВт (потребляемой, которые отдают 3 кВт холода), итого 5 кВт подводимой мощности. А для нее нам нужно что ??? Правильно ИБП )) и запас батарей к нему )))) и резервный генератор )))))
И вот что мы имеем в итоге? Электронику - которая потребляет 2,3кВ и охлаждение к ней которое в среднем будет потреблять от 0,6кВт (только куллеры постоянно) и в пиках до 2,6 кВт с кондиционерами (в среднем кондиционеры 1кВт)
На полезное потребление 2,3 кВт тратится паразитных 1,6 кВт это около 70-ТИ процентов!!!!!!!! А стоимость резервного питания вырастает более чем в 2 раза (полезных 2,3 кВт а всего 5 кВт.) и эта стоимость при условии стоимости акб около $250/кВт*ч очень кусается. Так как при резерве на 2 часа нужно $2500 на батарейку каждые 3-4 года. А если на 10ть часов (((((
Мы же планируем сократить расходы на охлаждение с 70% до 10% таким образом будут не нужны кондиционеры, ИБП двойной мощности и батареи к нему. Что, в свою очередь, позволит нам при тех же условиях разместить оборудования в 2 раза больше. Соответственно понизить себестоимость сервиса, снизить цены на услуги, что автоматом повысит количество клиентов и наш заработок. Ведь себестоимость эксплуатации у нас в 4-5 раз ниже чем у конкурентов.
Такие дела товарищи.
P.S. данные энергопотребления взяты с реального оборудования и несколько раз перепроверены.
Нам нужно получить:
Система охлаждения.
Воздушную систему охлаждения эффективной особо не назовешь, нужно что-то другое, как вариант трансформаторное масло.
Плюсы:
· достаточно эффективная система потому что полностью равномерное отведение тепла (включая те места где воздухом не охлаждается или плохо охлаждается )
· из-за равномерного отвода тепла — компоненты матери проживут дольше
· из-за большей теплоемкости масла - нет резких перепадов температуры в охлаждении
· снижается расход электричества, за счет отсутствия куллеров
· решается проблема с статикой и вихревыми токами
· тепло получаем не в виде горячего воздуха в серверной, а в жидком виде.
· тепло в жидком виде можно дальше использовать как вздумается (куда его девать придумаем потом, пока зима — оно и в офисе не помешает)
· хочется увидеть (но яро не горю желанием) глаза тех кто попытается изъять это оборудование
· тишина!!!
Минусы
· все в масле (не самые приятные ощущения + постоянно руки мыть нужно), но пережить можно ))
· если вдруг что-то случится с системой охлаждения, масло дотечет до подвала ( > 200литров, 4 этажа вниз) и будут проблемы с собственником здания
Так как мы хотим все быстрее, пока основную систему не доделали и не запустили, используем батарею отопления + насос + емкость для погрузки железяк.
С охлаждением +/- разобрались, дальше нужно железо которое будет работать.
покупаем серверные материнские платы + процы + ОЗУ, все без корпусов, так значительно дешевле и они все равно не нужны
Источник питания мат плат.
Для максимальной эффективности этого момента, нужно еще думать о резервном питании.
В инструкции к матерям написано что им для работы нужно +12 (основной) +5 (дежурка) и контакт который мать замыкает на массу для запуска блока питания.
В целом все ясно, у нас были 2 блока питания с сервера HP, в сумме они 1,2 кВт (два по 600 Вт)
но у нас на старте 4 матери, нужно или 4 блока питания или думать что-то еще.
Выбираем второй вариант, блоки питания в будущем нам все равно не нужны будут потому их покупать смысла нет.
Берем герконовое реле + автомобильное реле (с фар), масса от матери включает герконовое реле которое включает автомобильное.
Получили независимое от блока питания отключение/включение материнских плат, нужно только обеспечить дежуркой ( +5 ), оно есть на блоках питания.
Включаем параллельно блоки питания, получаем 1,2 кВт блок питания, матери в полной комплектации предельно потребляют около 400Вт, блока питания для 4х матерей хватит + они не в полной комплектации, хватает с избытком, идем дальше.
Первые 3 пункта
Пункт 2 — подразумевает само назначение кластера, возможность его масштабировать это скорее правильное развертывание чем конечная цель, остается только то что нам нужен кластер.
По итогу должно получится что-то вроде такого.
Где сервера (ноды) держат на себе виртуальные машины, все это соединяется несколькими сетями с сервером дисков.
Описываю так как это вижу я, поэтому могут быть не точности (по причине отсутствия спец образования).
Попытаюсь ответить на вопрос зачем это нужно или зачем это нужно мне.
Что для вас надежное и безопасное хранение файлов?
Где и как хранить свои файлы?
Где и как хранить файлы по работе?
Как при необходимости быстро получить доступ к необходимым файлам?
Как при необходимости быстро получить доступ к вычислительным ресурсам?
Что вообще значит безопасно?
Чем еще заняться когда заниматься уже ничем не хочется?
Определения на вики:
Безопасность — это такие условия, в которых находится сложная система, когда действие внешних и внутренних факторов не влечёт действий, считающихся отрицательными по отношению к данной сложной системе в соответствии с существующими на данном этапе потребностями, знаниями и представлениями.
Безопасность — такое состояние сложной системы, когда действие внешних и внутренних факторов не приводит к ухудшению системы или к невозможности её функционирования и развития.
Безопасность — многозначное понятие, характеризующее в первую очередь защищённость и низкий уровень риска для человека, общества или любых других субъектов, объектов или их систем.
Как не назови но это комплекс мер, которые защищают что-то от чего-то.
Так как комплекс мер это не единая мера, следовательно то что безопасно для нас сейчас не говорит о том что это будет безопасно завтра.
Есть вариант держать все за границей на арендованных серверах, держать пачку фейков с них оплачивать и тд — если кратко, был опыт, лично мне он не совсем подходит.
Вспоминая как происходит процесс изъятия техники нашими органами (работал системным администратором в нескольких фирмах которые так выносили + было две свои студии с webcam моделями + опыт коллег по обыденной жизни), появилось ряд видений как быть дальше.
Я планирую сделать (грубо):
Физически защитить и скрыть металлический ящик гораздо проще чем серверную комнату.
Масло даст доп препятствии доступа к железу и герметичность, система питания даст возможность все корректно забекапить убыть и выключить, шифрование скроет все что нельзя было использовать или нужно было купить.
Имена сетевых карт на windows серверах задаем одинаковые, чтобы не путаться.
LAN1 — первая сетевая карта (Ethernet 1Gbit/s)
LAN2 — вторая сетевая карта (Ethernet 1Gbit/s)
SAN1 — первая сетевая карта (Infiniband 20Gbit/s)
SAN2 — вторая сетевая карта (Infiniband 20Gbit/s)
Так как у меня на серверах по 2 порта Ethernet 1Gbit/s и Infiniband сетевки двух портовые, поэтому присутствует в описании SAN2, в будущем этот порт задействуем для дублирования Infiniband свитча (как минимум когда второй Infiniband свитч появится) пока просто не используем.
Указанные модели железяк - это просто как вариант, железо которое у меня есть/было
Организация кластера.
Нам нужно :
Проблема выглядела как: сетевая карта есть, но кабель не подключен.
Спустя неделю, хороший человек, подсказал что для работы сети Infiniband нужна служба/демон именуемый «subnet manager» к ней периодически обращается сеть чтобы понять то что ей нужно понимать.
Очередной проблемой вылезло то где ее запустить.
Хотелось все сделать на Windows Server 2012 R2, но subnet manager (использовал OpenSM) упорно работать не хотел, хотя в логах писало что все ок, сеть поднята все хорошо и тд. но сеть не работала.
Получилось без особых проблем запустить на Windows 2008 R2 и на linux .
Так как Windows 2008 R2 использовать не хотелось, разместил на linux, который пока будет как шлюз в инет для кластера и виртуальных машин и как мост для сетей SAN (Infiniband 20Gbit/s) и LAN (Ethernet 1Gbit/s) чтобы обеспечить избыточность сети для кластера.
Машина которая будет выполнять роли шлюза, назовем ее SAN01
Мощностей особых не нужно, это обычный маршрутизатор на базе компьютера, ставим linux ставим сетевые карты у нас 5 сетевых интерфейса (3шт LAN и 2шт SAN)
Одну сетевку используем как WAN, вторую как LAN на третьей создаем несколько vlan
Можно сократить количество сетевых карт, но так наглядней.
Настраиваем FORWARD между LAN и SAN и MASQUERADE через WAN порт.
Настройка базовая, ничего не мудрил, так как в качестве шлюза для кластера в будущем будет другая машина, а виртуальные машины будут выходить через свои шлюзы с туннелями.
Поднимаем OpenSM (subnet manager),
итого у нас шлюз для всех сетей
У него настройки сетевых карт:
eth0 — наш внешний IP (выход в инет)
eth1 — 172.16.0.1/28
eth2 — не задан, он для vlan
ib0 — 172.16.1.1/28 (Сеть SAN первая сетевка)
ib1 — 172.16.2.1/28 (Сеть SAN вторая сетевка, дальше ее пока использовать не будем)
vlan101 — 172.16.101.1/28 vlan интерфейс через eth2
vlan102 — 172.16.102.1 /28 vlan интерфейс через eth2
vlan103 — 172.16.103.1/28 vlan интерфейс через eth2
И тд vlan столько сколько нужно через них будут выходить в мир виртуальные машины
Подключились, eth1 — в свитч LAN, ib0 — в свитч SAN
Дальше берем сервер который будет держать на себе все диски кластера обзовем его SAN02
Ставим Windows Server 2012 R2, поднимаем роли: сервер целей iSCSI и Hyper-V
Работать это все будет на Windows Server 2012 R2 все шлюзы на debian linux
Естественно для Windows кластер, Microsoft требует использовать Active Directory, поэтому кластер без него не запустишь.
Очередная проблема, если не будет в сети Active Directory — кластер работать не будет, если не будет сервера с дисками — проблема та же.
При установке роли ADDS инсталлятор сам отключает кэширование для всех логических дисков, на которых находятся базы и логи ADDS.
Поэтому совместить роль с сервером целей iSCSI — не лучшая мысль.
С учетом того что техники не особо много, конфигурацию в AD менять часто не будем и будем делать резервные копии, пока ограничился одним виртуальным сервером с AD в качестве контроллера домена для кластера.
Подымаем виртуальную машину второго поколения с Windows Server 2012 R2,
настраиваем на нем Active Directory,
настраиваем нужные параметры и политики что-бы не настраивать в ручную на каждом сервере.
Отдельно рекомендовал-бы включить удаленный рабочий стол и открыть нужные порты в фаерволе
и не забываем в настройках виртуальной машины поставить необходимость ее всегда запускать.
Разрешаем доступ к сети кластера, в Hyper-V создаем внешнюю виртуальную сеть и привязываем ее к LAN1
Ставим галочку Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру
Таким образом он будет у нас включен тогда когда включен и сервер с дисками.
В настройках виртуальной машины не забываем указать что машину нужно всегда запускать.
сеть сервераSAN02 (он-же сервер с дисками)
LAN1 — 172.16.0.4/28 GW 172.16.0.1 DNS 172.16.0.5
SAN1 — 172.16.1.4/28 GW 172.16.1.1
Сеть сервера AD01 (виртуальный сервер с Active Directory который крутится на SAN02)
LAN1 — 172.16.0.5/28 GW 172.16.0.1 (общее использование интерфейса LAN1 сервера SAN02 )
У нас получилось примерно следующее.
Дальше берем сервера которые будут нодами кластера
Ставим Windows Server 2012 R2, делаем базовую настройку, потом откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V и следующим шагом добавим компоненту Отказоустойчивая кластеризация.
На странице настройки виртуальных коммутаторов выбираем LAN1
После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов.
Их название на обоих узлах должно полностью совпадать (виртуальная машина после перемещения на другую ноду будет искать свой виртуальный свитч по его имени, поэтому имена нужны одинаковые).
сеть сервера NODE1
сеть сервера NODE2
Заводим все машины в домен Active Directory (SAN02 можно не вводить, не особо принципиальный момент, просто так им удобней управлять.
Получили примерно следующее.
Перейдем к серверу хранилища (SAN02).
Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин.
Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.
Создайте новую цель iSCSI и разрешите доступ к ней инициаторам в качестве которых будут выступать узлы кластера (ноды)
И сопоставляем данной цели созданные виртуальные диски
Настроив хранилище, вернемся на NODE1 и подключим диски из хранилища.
Помните, что если сервер хранилища подключен также к локальной сети, то при подключении к цели iSCSI укажите для доступа сеть хранения данных.
Подключенные диски инициализируем и форматируем.
Затем переходим на второй узел и также подключаем диски, форматировать их уже не надо, просто присваиваем им такие же самые буквы и метки тома. Это необязательно, но желательно сделать в целях единообразия настроек, когда одинаковые диски на всех узлах имеют одни и те-же обозначения запутаться и сделать ошибку гораздо труднее.
Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию.
В настройках мастера добавим настроенные нами узлы ( NODE1 и NODE2 ) и выберем выполнение всех тестов.
Если все ок — кластер создан, осталось проверить/настроить сеть, настроить приоритеты сети и убедиться что нагрузка по тем сетевым картам которые необходимы.
Так как топик не вызвал интереса. Спрошу еще раз, это вообще кто-то читает?)))
Опишу что получилось в конечном итоге.
Настраиваем на свиче порты 13-20 как транковые, чтобы пропускали через себя тегированый трафик, это дает возможность каждой виртуальной машине иметь свою сеть к шлюзу который ее будет выпускать в инет. Шлюзы настраиваем как клиент OpenVPN, для того что-бы не светить что это туннель, на наружном сервере (OpenVPN сервер) закрываем ICMP протокол (пинг), это нужно потому что (грубо) сайт делает пинг на свой сервер с браузера и получает значение X потом сервер делает ответный пинг на IP с которого пришел пинг и получает значение Y, если X и Y сильно разные — вы 100% работаете через туннель какого-то вида:
Если сервер через который вы выходите в инет не будет отвечать на пинги, сервер не сможет получить значение Y и такой алгоритм проверки тогда не работает. В свою очередь, проверить туннель это или нет, можно дальше только по значению MTU.
более подробно написано тут https://habrahabr.ru/post/216295/
Если кратко, зная значение вашего MTU как пример 1409 - то с большей долей вероятности вы используете OpenVPN UDP bs64 SHA1, спасибо автору статьи.
Вариант решения который я нашел методом подбора значения, в конфиге OpenVPN сервера ставим параметр: tun-mtu 1100
+ минимальные настройки в браузерах, что-бы он сам не стучал куда не нужно.
Задача шлюза давать сети виртуальных машин (VM) только инет через openvpn сервер. Как шлюз будет подключен к инету что-бы достучаться к openvpn серверу — это уже второй вопрос, главное что-бы при любом из вариантов, виртуальная машина не вышла в инет с инета шлюза (Только через туннель vpn или связь отсутствовала.)
Подключиться к нужной виртуальной машине вы можете либо через любой из шлюзов, или выделить отдельный шлюз, таким образом канал управления VM и рабочий канал доступа к сети Интернет не будут пересекаться и если поставите что-то загружать с инета — не пропадет управляемость + IP к которому вы подключаетесь будет не такой как тот с которого работаете.
В моем случае это шлюз с веб сервером, который открывает порт на нужную мне виртуальную машину для IP с которого я в данный момент подключен. Таким образом при сканировании IP с мира — видно что работает только web сервер, больше открытых портов нет и он-же занимается и закрытием порта, через указанное время, чтобы исключить возможность потенциально забыть закрыть себе доступ.
Пример куска кода для открытия и перенаправления порта (php)
где
Кластер дает возможность увеличивать свои вычислительные ресурсы, так-же он дает возможность запускать виртуальную машину на любом узле кластера (для отказоустойчивости) но это так-же позволяет:
· создать виртуальную машину как шаблон, устанавливаем на нем весь софт который нужен и если он привязан к железу — лицензии улетать не будут
· создавать разностные диски, так каждая новая виртуальная машина на основе шаблона будет занимать место только то что вы в ней запишете(то есть: vm1(шаблон)=4gd; vm2+500mb новой инфы=500mb; vm3+10kb новой инфы=10kb; vm1+vm2+vm3=4500010kb)
· создавать / приостанавливать / хранить любое количество виртуальных машин это не накладно по ресурсам
Касательно шифрования:
Все сервера используют MBR и находятся в одном сегменте локальной сети, на любой машине которая как шлюз или берем Raspberry Pi, настраиваем tftp и dhcp сервер, монтируем файловую систему любого облака или WebDAV диска для хранения ключей дешифровки, используя https://diskcryptor.net шифруем и создаем ключи для загрузки через pxe. Таким образом все диски серверов шифруем и ключи дешифровки у вас на внешнем сервере.
Описывать резервирование или как делать backup и т.д. уже не буду, это и так понятно, мануалов масса.
Добавлю только что использование Raspberry Pi и arduino позволяют решить многие вопросы по управляемости и контролю среды где работает кластер и управлять при авариях или событиях основываясь на датчиках, камерах видеонаблюдения и т.д..
Что это мне дает в конечном итоге:
· экономия электричества и экономия на бесперебойном питании, авто запуск генератора
· выполнение алгоритма действий. запуск программ или устройств на основании событий (используя аппаратные и программные датчики)
· защита данных с возможностью их автоматического экспорта на другой кластер или удалением с этого.
· Возможность автоматического дублирования кластера (репликация всех VM на другой кластер), на случай необходимости уничтожения рабочего кластера.
· экономия на программах которые привязаны к железу, если не хватает мощности нужно добавить ноду в кластер (мать + проц + озу + диск для запуска (если нет загрузки ноды по сети) ), а не искать новую железяку и покупать на нее софт.
· Использование арендованных самых дешевых VDS как точка выхода трафика VM или как простой прокси сервер.
· экономия самых дешевых VDS (используя API приостанавливаем VDS и платим только за ее хранение, а не использование) какой VDS включать, а какой нет — контролирует web сервер который дает доступ. (в моем случае VDS в работе — 320wmr/месяц, а хранение 50wmr/месяц ), хоть и мелочи но так можно держать в готовности достаточное количество серверов для выхода в инет без больших затрат (хотя уже написал скрипт который настраивает OpenVPN сервер и OpenVPN клиент (шлюз) в нужную мне конфигурацию, таким образом в случае необходимости создание новой пары шлюз-сервер занимает автоматом до 5 минут)
· предварительную платформу для связи (каждый скайп, sip телефон, jabber работает с своего IP и сводится в одну точку )
· OS с которой хочешь работать — какую поставишь, такая и будет
· нет ничего лишнего на компьютере с которого работаешь
· доступ по умолчанию закрыт и открываешь по необходимости
· возможность коллективной работы.
Список можно продолжать долго и ограничивается только фантазией.
Для тех кто еще ничего не понял, но очень хочет) Следующее фото:
На данный момент, мы видим материнскую плату погруженную в трансформаторное масло вместе с блоком питания и всеми необходимыми элементами для полноценного запуска системы. Если вы видите индикатор зеленого цвета, то можете понять что сейчас мать включена и работает без проблем) Масло с помощью циркуляционного насоса прогоняется через систему охлаждения, она же батарея) Тем самым охлаждает жидкость в бочке. На процах висит по радиатору и никаких кулеров. Напомню это тестовый вариант. Вообще в планах на ближайшие дни, поднять железо, которое будет стоять вот в этой компактной
емкости.
Кстати масло уже приобрел и оно ожидает своего часа)
Что хочу что бы получилось в итоге. Для тех кто понимает о чем идет речь и шарит в отрасли серверного оборудования и его настройки.
Сервер на котором находятся все данные (на картинке SRV12R2-STOR).
к нему через infiniband подключены сервера без дисков (ноды) на которых будут работать виртуалки.
В общем вот такое интересное дело. В тему буду кидать новости о продвижении, если конечно будет актуально для кого-то.
Емкость закрытая, поскольку масло имеет запах и оно гигроскопично. Масло на первых фото почти не имеет резкого запаха, его почти не слышно. А вот перед этим, было другое масло, оно воняло ппц. В помещении долго находится было очень тяжело) Вот кстати тест первого запуска с маслом. С тем которое воняло.
Масло трансформаторное Т-1500 сернокислотной и селективной очисток, вырабатываемое из малосернистых нефтей. Применяются для масляных выключателей и другой высоковольтной аппаратуры (напряжением до 500 кВ) в качестве основного электроизоляционного материала. Оно не простое)) Это масло тоже из авто-магазина,, моторное масло не подойдет.
Вот еще по маслу: "Трансформаторные масла́ — минеральные масла высокой чистоты и низкой вязкости. Применяются для заливки силовых и измерительных трансформаторов, реакторного оборудования, а также масляных выключателей. Предназначено для изоляции находящихся под напряжением частей и узлов силового трансформатора, отвода тепла от нагревающихся при работе трансформатора частей, а также предохранения изоляции от увлажнения."
Сейчас вот готовлю к погружению.
Это спаренные IBM БП 12V 49A (12V 98A, 1.2kW)
Тут 4 Xeon X5570 96гб ОЗУ.
Продолжаем)
Нам нужно получить:
1. отказоустойчивый кластер
2. возможность увеличения мощности путем добавления железа
3. возможность управлять всем удаленно
4. максимально эффективная система охлаждения
5. максимально эффективная система основного питания
6. максимально эффективная система резервного питания
7. максимальная плотность размещения серверов
8. максимально минимальная цена (в рамках разумного)
Так как сервера которые есть выводить из эксплуатации пока нельзя, придется покупать новые железяки и их должно хватить на организацию кластера и свободных ресурсов кластера по итогу должно быть не меньше чем у минимального сервера который в данный момент работает (что бы по очереди всех существующих клиентов пересадить на кластер, а сервера добавить как узлы (ноды) кластера)
Система охлаждения.
Воздушную систему охлаждения эффективной особо не назовешь, нужно что-то другое, как вариант трансформаторное масло.
Плюсы:
· достаточно эффективная система потому что полностью равномерное отведение тепла (включая те места где воздухом не охлаждается или плохо охлаждается )
· из-за равномерного отвода тепла — компоненты матери проживут дольше
· из-за большей теплоемкости масла - нет резких перепадов температуры в охлаждении
· снижается расход электричества, за счет отсутствия куллеров
· решается проблема с статикой и вихревыми токами
· тепло получаем не в виде горячего воздуха в серверной, а в жидком виде.
· тепло в жидком виде можно дальше использовать как вздумается (куда его девать придумаем потом, пока зима — оно и в офисе не помешает)
· тишина!!!
Минусы
· все в масле (не самые приятные ощущения + постоянно руки мыть нужно), но пережить можно ))
· если вдруг что-то случится с системой охлаждения, масло дотечет до подвала ( > 200литров, 4 этажа вниз) и будут проблемы с собственником здания
Так как мы хотим все быстрее, пока основную систему не доделали и не запустили, используем батарею отопления + насос + емкость для погрузки железяк. С охлаждением +/- разобрались, дальше нужно железо которое будет работать. Покупаем серверные материнские платы + процы + ОЗУ, все без корпусов, так значительно дешевле и они все равно не нужны
Источник питания мат плат.
Для максимальной эффективности этого момента, нужно еще думать о резервном питании. В инструкции к матерям написано что им для работы нужно +12 (основной) +5 (дежурка) и контакт который мать замыкает на массу для запуска блока питания. В целом все ясно, у нас были 2 блока питания с сервера IBM, в сумме они 1,2 кВт (два по 600 Вт) но у нас на старте 4 матери, нужно или 4 блока питания или думать что-то еще. Выбираем второй вариант, блоки питания в будущем нам все равно не нужны будут, потому их покупать смысла нет. Берем герконовое реле + автомобильное реле (с фар), масса от матери включает герконовое реле которое включает автомобильное. Получили независимое от блока питания отключение/включение материнских плат, нужно только обеспечить дежуркой ( +5 ), оно есть на блоках питания.
Включаем параллельно блоки питания, получаем 1,2 кВт блок питания, матери в полной комплектации предельно потребляют около 400Вт, блока питания для 4х матерей хватит + они не в полной комплектации, хватает с избытком.
Главный ответ: огород посажен уже давно. Я провожу его модернизацию. Зачем мне арендовать сервер, если я сдаю свои сервера в аренду))) Это "барахло" не предназначено для использования в домашних условиях.
Предоставлять ничего не собираюсь, пока) Все что есть, работает и загружено по максимуму, 24/7. Тему создал для того что бы поделиться опытом с людьми которые занимаются серверным оборудованием. Может у кого-то из клуба есть свои серваки, а они даже не задумывались о таком решении. Так же может кто-то уже реализовал данный метод и поделится опытом)))
Железяка была погружена в масло, успешно запущена и находится в процессе настройки.
Температурный режим:
В помещении +18 °С, с данной системой охлаждения, 50 литров масла, на каждой мамке стоит по системе, в режиме простоя +46 °С
Знакомо мне все это , сам лет 5 назад занимался плотно этим, только для сферы игровой индустрии (более 14 серверов на машине крутилось). Можно сказать хобби, в то время как работал в крупном интернет провайдере. Проектировал под это дело сервер с СВО, конечно, можно было и залмановскую готовую взять, но делал все самостоятельно, начиная от фрезировки элементов блока охлаждения на станках с ЧПУ, модели разные в солиде делал, эффективность считал, благо болванок медных было много. Покупал все сопутствующее в авто- и садовых магазинах. Все это было связано с ИБП, находилось на лоджии. Сервера работали бесперебойно, но было одно НО. В своих сообщениях ты пишешь о надежной системе основного питания, резервного, но ни слова о самом узком месте - канале связи, с которым у меня в свою очередь тоже были проблемы. Потому что при его отказе, вся эта система превращается в груду железа, в моем случае - работающая на воде, в твоем на маслеЕсли ты до сих пор этот вопрос не решил (ну раз не писал о резервных каналах связи в проекте), то подумай обязательно. У меня решился он только после подключения еще двух провайдеров интернет от разных магистралей.
Успехов тебе!
Да была такая проблема, до того момента пока не подписал договор с двумя самыми крупными провайдерами в городе на уровень обслуживания 99,9%, это конечно не пять девяток, но пока что есть, альтернативы пока все равно нет, в будущем придумаю как добавить еще каналов.
С другой стороны: 88 часов простоя в год, да плохо, но это все равно уже лучше чем 1 канал и без SLA
Кроме того, система охлаждения 1U сервера основана на 6-8 ми спаренных кулерах по 14- 20-ти ват на каждый. И поверьте они (куллеры) не простаивают. А это минимум 50-60 Вт. при простое сервера, и под 100 Вт при полной нагрузке. (при потреблении самого железа около 300-350 Вт.).
То есть около 30% энергии тратится при охлаждении в пустую. В принципе это само по себе не страшно, но потом это тепло утилизируется кондиционером с еще 30-40 %-ми затрат.
Это все тоже не так страшно, пока мы не доходим до пункта охлаждения и бесперебойного питания в целом. При мощности оборудования 3кВт (сама электроника будет потреблять 2,4 кВт и 0,6 кВт куллеры) потребуется 2 кондиционера мощн. по 1кВт (потребляемой, которые отдают 3 кВт холода), итого 5 кВт подводимой мощности. А для нее нам нужно что ??? Правильно ИБП )) и запас батарей к нему )))) и резервный генератор )))))
И вот что мы имеем в итоге? Электронику - которая потребляет 2,3кВ и охлаждение к ней которое в среднем будет потреблять от 0,6кВт (только куллеры постоянно) и в пиках до 2,6 кВт с кондиционерами (в среднем кондиционеры 1кВт)
На полезное потребление 2,3 кВт тратится паразитных 1,6 кВт это около 70-ТИ процентов!!!!!!!! А стоимость резервного питания вырастает более чем в 2 раза (полезных 2,3 кВт а всего 5 кВт.) и эта стоимость при условии стоимости акб около $250/кВт*ч очень кусается. Так как при резерве на 2 часа нужно $2500 на батарейку каждые 3-4 года. А если на 10ть часов (((((
Мы же планируем сократить расходы на охлаждение с 70% до 10% таким образом будут не нужны кондиционеры, ИБП двойной мощности и батареи к нему. Что, в свою очередь, позволит нам при тех же условиях разместить оборудования в 2 раза больше. Соответственно понизить себестоимость сервиса, снизить цены на услуги, что автоматом повысит количество клиентов и наш заработок. Ведь себестоимость эксплуатации у нас в 4-5 раз ниже чем у конкурентов.
Такие дела товарищи.
P.S. данные энергопотребления взяты с реального оборудования и несколько раз перепроверены.
Нам нужно получить:
- отказоустойчивый кластер
- возможность увеличения мощности путем добавления железа
- возможность управлять всем удаленно
- максимально эффективная система охлаждения
- максимально эффективная система основного питания
- максимально эффективная система резервного питания
- максимальная плотность размещения серверов
- максимально минимальная цена (в рамках разумного)
Система охлаждения.
Воздушную систему охлаждения эффективной особо не назовешь, нужно что-то другое, как вариант трансформаторное масло.
Плюсы:
· достаточно эффективная система потому что полностью равномерное отведение тепла (включая те места где воздухом не охлаждается или плохо охлаждается )
· из-за равномерного отвода тепла — компоненты матери проживут дольше
· из-за большей теплоемкости масла - нет резких перепадов температуры в охлаждении
· снижается расход электричества, за счет отсутствия куллеров
· решается проблема с статикой и вихревыми токами
· тепло получаем не в виде горячего воздуха в серверной, а в жидком виде.
· тепло в жидком виде можно дальше использовать как вздумается (куда его девать придумаем потом, пока зима — оно и в офисе не помешает)
· хочется увидеть (но яро не горю желанием) глаза тех кто попытается изъять это оборудование
· тишина!!!
Минусы
· все в масле (не самые приятные ощущения + постоянно руки мыть нужно), но пережить можно ))
· если вдруг что-то случится с системой охлаждения, масло дотечет до подвала ( > 200литров, 4 этажа вниз) и будут проблемы с собственником здания
Так как мы хотим все быстрее, пока основную систему не доделали и не запустили, используем батарею отопления + насос + емкость для погрузки железяк.
С охлаждением +/- разобрались, дальше нужно железо которое будет работать.
покупаем серверные материнские платы + процы + ОЗУ, все без корпусов, так значительно дешевле и они все равно не нужны
Источник питания мат плат.
Для максимальной эффективности этого момента, нужно еще думать о резервном питании.
В инструкции к матерям написано что им для работы нужно +12 (основной) +5 (дежурка) и контакт который мать замыкает на массу для запуска блока питания.
В целом все ясно, у нас были 2 блока питания с сервера HP, в сумме они 1,2 кВт (два по 600 Вт)
но у нас на старте 4 матери, нужно или 4 блока питания или думать что-то еще.
Выбираем второй вариант, блоки питания в будущем нам все равно не нужны будут потому их покупать смысла нет.
Берем герконовое реле + автомобильное реле (с фар), масса от матери включает герконовое реле которое включает автомобильное.
Получили независимое от блока питания отключение/включение материнских плат, нужно только обеспечить дежуркой ( +5 ), оно есть на блоках питания.
Включаем параллельно блоки питания, получаем 1,2 кВт блок питания, матери в полной комплектации предельно потребляют около 400Вт, блока питания для 4х матерей хватит + они не в полной комплектации, хватает с избытком, идем дальше.
Первые 3 пункта
- отказоустойчивый кластер
- возможность увеличения мощности путем добавления железа
- возможность управлять всем удаленно
Пункт 2 — подразумевает само назначение кластера, возможность его масштабировать это скорее правильное развертывание чем конечная цель, остается только то что нам нужен кластер.
По итогу должно получится что-то вроде такого.
Где сервера (ноды) держат на себе виртуальные машины, все это соединяется несколькими сетями с сервером дисков.
Описываю так как это вижу я, поэтому могут быть не точности (по причине отсутствия спец образования).
Попытаюсь ответить на вопрос зачем это нужно или зачем это нужно мне.
Что для вас надежное и безопасное хранение файлов?
Где и как хранить свои файлы?
Где и как хранить файлы по работе?
Как при необходимости быстро получить доступ к необходимым файлам?
Как при необходимости быстро получить доступ к вычислительным ресурсам?
Что вообще значит безопасно?
Чем еще заняться когда заниматься уже ничем не хочется?
Определения на вики:
Безопасность — это такие условия, в которых находится сложная система, когда действие внешних и внутренних факторов не влечёт действий, считающихся отрицательными по отношению к данной сложной системе в соответствии с существующими на данном этапе потребностями, знаниями и представлениями.
Безопасность — такое состояние сложной системы, когда действие внешних и внутренних факторов не приводит к ухудшению системы или к невозможности её функционирования и развития.
Безопасность — многозначное понятие, характеризующее в первую очередь защищённость и низкий уровень риска для человека, общества или любых других субъектов, объектов или их систем.
Как не назови но это комплекс мер, которые защищают что-то от чего-то.
Так как комплекс мер это не единая мера, следовательно то что безопасно для нас сейчас не говорит о том что это будет безопасно завтра.
Есть вариант держать все за границей на арендованных серверах, держать пачку фейков с них оплачивать и тд — если кратко, был опыт, лично мне он не совсем подходит.
Вспоминая как происходит процесс изъятия техники нашими органами (работал системным администратором в нескольких фирмах которые так выносили + было две свои студии с webcam моделями + опыт коллег по обыденной жизни), появилось ряд видений как быть дальше.
Я планирую сделать (грубо):
- металлический ящик в котором поместится достаточное количество серверов
- не должно быть шума, это очень палевно
- минимальный расход эл. энергии
- встроенный бесперебойник
- если сломался сервак, его задачи удаленно или автоматом перенести на другой сервер
- лучше потерять информацию чем она попадет не в те руки
- всегда должна быть резервная копия данных но на совершенно других серверах.
- все файлы всегда должны быть зашифрованы
- ключ дешифровки подключаем удаленно, на месте его не храним
- возможность полного отключения и закуска с дешифровкой на 100% удаленно
Физически защитить и скрыть металлический ящик гораздо проще чем серверную комнату.
Масло даст доп препятствии доступа к железу и герметичность, система питания даст возможность все корректно забекапить убыть и выключить, шифрование скроет все что нельзя было использовать или нужно было купить.
Имена сетевых карт на windows серверах задаем одинаковые, чтобы не путаться.
LAN1 — первая сетевая карта (Ethernet 1Gbit/s)
LAN2 — вторая сетевая карта (Ethernet 1Gbit/s)
SAN1 — первая сетевая карта (Infiniband 20Gbit/s)
SAN2 — вторая сетевая карта (Infiniband 20Gbit/s)
Так как у меня на серверах по 2 порта Ethernet 1Gbit/s и Infiniband сетевки двух портовые, поэтому присутствует в описании SAN2, в будущем этот порт задействуем для дублирования Infiniband свитча (как минимум когда второй Infiniband свитч появится) пока просто не используем.
Указанные модели железяк - это просто как вариант, железо которое у меня есть/было
Организация кластера.
Нам нужно :
- сервер который будет выступать в качестве дискового хранилища, (купить готовое решение не является возможным поэтому сервер)
- ноды кластера (то где будет работать виртуальная машина, в моем случае пока будет 2 потом добавлю)
- шлюз в инет
- Свитч HP 1810-48G (J9660A) Управляемый, 4 x SFP, 48 x Gigabit Ethernet (10/100/1000 Мбит/с)
- СвитчFlextronics 24-Port Infiniband Switch 20Gbit/s DDR
- Active Directory для кластера
Проблема выглядела как: сетевая карта есть, но кабель не подключен.
Спустя неделю, хороший человек, подсказал что для работы сети Infiniband нужна служба/демон именуемый «subnet manager» к ней периодически обращается сеть чтобы понять то что ей нужно понимать.
Очередной проблемой вылезло то где ее запустить.
Хотелось все сделать на Windows Server 2012 R2, но subnet manager (использовал OpenSM) упорно работать не хотел, хотя в логах писало что все ок, сеть поднята все хорошо и тд. но сеть не работала.
Получилось без особых проблем запустить на Windows 2008 R2 и на linux .
Так как Windows 2008 R2 использовать не хотелось, разместил на linux, который пока будет как шлюз в инет для кластера и виртуальных машин и как мост для сетей SAN (Infiniband 20Gbit/s) и LAN (Ethernet 1Gbit/s) чтобы обеспечить избыточность сети для кластера.
Машина которая будет выполнять роли шлюза, назовем ее SAN01
Мощностей особых не нужно, это обычный маршрутизатор на базе компьютера, ставим linux ставим сетевые карты у нас 5 сетевых интерфейса (3шт LAN и 2шт SAN)
Одну сетевку используем как WAN, вторую как LAN на третьей создаем несколько vlan
Можно сократить количество сетевых карт, но так наглядней.
Настраиваем FORWARD между LAN и SAN и MASQUERADE через WAN порт.
Настройка базовая, ничего не мудрил, так как в качестве шлюза для кластера в будущем будет другая машина, а виртуальные машины будут выходить через свои шлюзы с туннелями.
Поднимаем OpenSM (subnet manager),
итого у нас шлюз для всех сетей
У него настройки сетевых карт:
eth0 — наш внешний IP (выход в инет)
eth1 — 172.16.0.1/28
eth2 — не задан, он для vlan
ib0 — 172.16.1.1/28 (Сеть SAN первая сетевка)
ib1 — 172.16.2.1/28 (Сеть SAN вторая сетевка, дальше ее пока использовать не будем)
vlan101 — 172.16.101.1/28 vlan интерфейс через eth2
vlan102 — 172.16.102.1 /28 vlan интерфейс через eth2
vlan103 — 172.16.103.1/28 vlan интерфейс через eth2
И тд vlan столько сколько нужно через них будут выходить в мир виртуальные машины
Подключились, eth1 — в свитч LAN, ib0 — в свитч SAN
Дальше берем сервер который будет держать на себе все диски кластера обзовем его SAN02
Ставим Windows Server 2012 R2, поднимаем роли: сервер целей iSCSI и Hyper-V
Работать это все будет на Windows Server 2012 R2 все шлюзы на debian linux
Естественно для Windows кластер, Microsoft требует использовать Active Directory, поэтому кластер без него не запустишь.
Очередная проблема, если не будет в сети Active Directory — кластер работать не будет, если не будет сервера с дисками — проблема та же.
При установке роли ADDS инсталлятор сам отключает кэширование для всех логических дисков, на которых находятся базы и логи ADDS.
Поэтому совместить роль с сервером целей iSCSI — не лучшая мысль.
С учетом того что техники не особо много, конфигурацию в AD менять часто не будем и будем делать резервные копии, пока ограничился одним виртуальным сервером с AD в качестве контроллера домена для кластера.
Подымаем виртуальную машину второго поколения с Windows Server 2012 R2,
настраиваем на нем Active Directory,
настраиваем нужные параметры и политики что-бы не настраивать в ручную на каждом сервере.
Отдельно рекомендовал-бы включить удаленный рабочий стол и открыть нужные порты в фаерволе
и не забываем в настройках виртуальной машины поставить необходимость ее всегда запускать.
Разрешаем доступ к сети кластера, в Hyper-V создаем внешнюю виртуальную сеть и привязываем ее к LAN1
Ставим галочку Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру
Таким образом он будет у нас включен тогда когда включен и сервер с дисками.
В настройках виртуальной машины не забываем указать что машину нужно всегда запускать.
сеть сервераSAN02 (он-же сервер с дисками)
LAN1 — 172.16.0.4/28 GW 172.16.0.1 DNS 172.16.0.5
SAN1 — 172.16.1.4/28 GW 172.16.1.1
Сеть сервера AD01 (виртуальный сервер с Active Directory который крутится на SAN02)
LAN1 — 172.16.0.5/28 GW 172.16.0.1 (общее использование интерфейса LAN1 сервера SAN02 )
У нас получилось примерно следующее.
Дальше берем сервера которые будут нодами кластера
Ставим Windows Server 2012 R2, делаем базовую настройку, потом откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V и следующим шагом добавим компоненту Отказоустойчивая кластеризация.
На странице настройки виртуальных коммутаторов выбираем LAN1
После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов.
Их название на обоих узлах должно полностью совпадать (виртуальная машина после перемещения на другую ноду будет искать свой виртуальный свитч по его имени, поэтому имена нужны одинаковые).
сеть сервера NODE1
Code:
LAN1 — 172.16.0.6/28 GW 172.16.0.1 DNS 172.16.0.5
LAN2 — отдаем Hyper-V без галочки Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру и называем виртуальную сеть как VLAN
SAN1 — 172.16.1.6/28 GW 172.16.1.1сеть сервера NODE2
Code:
LAN1 — 172.16.0.7/28 GW 172.16.0.1 DNS 172.16.0.5
LAN2 — отдаем Hyper-V без галочки Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру и называем виртуальную сеть как VLAN
SAN1 — 172.16.1.7/28 GW 172.16.1.1Заводим все машины в домен Active Directory (SAN02 можно не вводить, не особо принципиальный момент, просто так им удобней управлять.
Получили примерно следующее.
Перейдем к серверу хранилища (SAN02).
Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин.
Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.
Создайте новую цель iSCSI и разрешите доступ к ней инициаторам в качестве которых будут выступать узлы кластера (ноды)
И сопоставляем данной цели созданные виртуальные диски
Настроив хранилище, вернемся на NODE1 и подключим диски из хранилища.
Помните, что если сервер хранилища подключен также к локальной сети, то при подключении к цели iSCSI укажите для доступа сеть хранения данных.
Подключенные диски инициализируем и форматируем.
Затем переходим на второй узел и также подключаем диски, форматировать их уже не надо, просто присваиваем им такие же самые буквы и метки тома. Это необязательно, но желательно сделать в целях единообразия настроек, когда одинаковые диски на всех узлах имеют одни и те-же обозначения запутаться и сделать ошибку гораздо труднее.
Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию.
В настройках мастера добавим настроенные нами узлы ( NODE1 и NODE2 ) и выберем выполнение всех тестов.
Если все ок — кластер создан, осталось проверить/настроить сеть, настроить приоритеты сети и убедиться что нагрузка по тем сетевым картам которые необходимы.
Так как топик не вызвал интереса. Спрошу еще раз, это вообще кто-то читает?)))
Опишу что получилось в конечном итоге.
Настраиваем на свиче порты 13-20 как транковые, чтобы пропускали через себя тегированый трафик, это дает возможность каждой виртуальной машине иметь свою сеть к шлюзу который ее будет выпускать в инет. Шлюзы настраиваем как клиент OpenVPN, для того что-бы не светить что это туннель, на наружном сервере (OpenVPN сервер) закрываем ICMP протокол (пинг), это нужно потому что (грубо) сайт делает пинг на свой сервер с браузера и получает значение X потом сервер делает ответный пинг на IP с которого пришел пинг и получает значение Y, если X и Y сильно разные — вы 100% работаете через туннель какого-то вида:
Если сервер через который вы выходите в инет не будет отвечать на пинги, сервер не сможет получить значение Y и такой алгоритм проверки тогда не работает. В свою очередь, проверить туннель это или нет, можно дальше только по значению MTU.
более подробно написано тут https://habrahabr.ru/post/216295/
Если кратко, зная значение вашего MTU как пример 1409 - то с большей долей вероятности вы используете OpenVPN UDP bs64 SHA1, спасибо автору статьи.
Вариант решения который я нашел методом подбора значения, в конфиге OpenVPN сервера ставим параметр: tun-mtu 1100
+ минимальные настройки в браузерах, что-бы он сам не стучал куда не нужно.
Задача шлюза давать сети виртуальных машин (VM) только инет через openvpn сервер. Как шлюз будет подключен к инету что-бы достучаться к openvpn серверу — это уже второй вопрос, главное что-бы при любом из вариантов, виртуальная машина не вышла в инет с инета шлюза (Только через туннель vpn или связь отсутствовала.)
Подключиться к нужной виртуальной машине вы можете либо через любой из шлюзов, или выделить отдельный шлюз, таким образом канал управления VM и рабочий канал доступа к сети Интернет не будут пересекаться и если поставите что-то загружать с инета — не пропадет управляемость + IP к которому вы подключаетесь будет не такой как тот с которого работаете.
В моем случае это шлюз с веб сервером, который открывает порт на нужную мне виртуальную машину для IP с которого я в данный момент подключен. Таким образом при сканировании IP с мира — видно что работает только web сервер, больше открытых портов нет и он-же занимается и закрытием порта, через указанное время, чтобы исключить возможность потенциально забыть закрыть себе доступ.
Пример куска кода для открытия и перенаправления порта (php)
Code:
shell_exec('sudo iptables -t nat -A PREROUTING --dst '.$_POST["destination_ip"].' -s '.$_POST["source_ip"].' -p tcp --dport '.$_POST["destination_port"].' -j DNAT --to-destination '.$_POST["lan_server_ip"].':'.$_POST["lan_server_port"] );где
Code:
$_POST["source_ip"] = $_SERVER["REMOTE_ADDR"]
$_POST["destination_ip"] = $_SERVER["SERVER_ADDR"]
$_POST["destination_port"] = порт на сервере который мы используем
$_POST["lan_server_ip"] = IP машины куда перенаправить
$_POST["lan_server_port"] = Порт машины куда перенаправитьКластер дает возможность увеличивать свои вычислительные ресурсы, так-же он дает возможность запускать виртуальную машину на любом узле кластера (для отказоустойчивости) но это так-же позволяет:
· создать виртуальную машину как шаблон, устанавливаем на нем весь софт который нужен и если он привязан к железу — лицензии улетать не будут
· создавать разностные диски, так каждая новая виртуальная машина на основе шаблона будет занимать место только то что вы в ней запишете(то есть: vm1(шаблон)=4gd; vm2+500mb новой инфы=500mb; vm3+10kb новой инфы=10kb; vm1+vm2+vm3=4500010kb)
· создавать / приостанавливать / хранить любое количество виртуальных машин это не накладно по ресурсам
Касательно шифрования:
Все сервера используют MBR и находятся в одном сегменте локальной сети, на любой машине которая как шлюз или берем Raspberry Pi, настраиваем tftp и dhcp сервер, монтируем файловую систему любого облака или WebDAV диска для хранения ключей дешифровки, используя https://diskcryptor.net шифруем и создаем ключи для загрузки через pxe. Таким образом все диски серверов шифруем и ключи дешифровки у вас на внешнем сервере.
Описывать резервирование или как делать backup и т.д. уже не буду, это и так понятно, мануалов масса.
Добавлю только что использование Raspberry Pi и arduino позволяют решить многие вопросы по управляемости и контролю среды где работает кластер и управлять при авариях или событиях основываясь на датчиках, камерах видеонаблюдения и т.д..
Что это мне дает в конечном итоге:
· экономия электричества и экономия на бесперебойном питании, авто запуск генератора
· выполнение алгоритма действий. запуск программ или устройств на основании событий (используя аппаратные и программные датчики)
· защита данных с возможностью их автоматического экспорта на другой кластер или удалением с этого.
· Возможность автоматического дублирования кластера (репликация всех VM на другой кластер), на случай необходимости уничтожения рабочего кластера.
· экономия на программах которые привязаны к железу, если не хватает мощности нужно добавить ноду в кластер (мать + проц + озу + диск для запуска (если нет загрузки ноды по сети) ), а не искать новую железяку и покупать на нее софт.
· Использование арендованных самых дешевых VDS как точка выхода трафика VM или как простой прокси сервер.
· экономия самых дешевых VDS (используя API приостанавливаем VDS и платим только за ее хранение, а не использование) какой VDS включать, а какой нет — контролирует web сервер который дает доступ. (в моем случае VDS в работе — 320wmr/месяц, а хранение 50wmr/месяц ), хоть и мелочи но так можно держать в готовности достаточное количество серверов для выхода в инет без больших затрат (хотя уже написал скрипт который настраивает OpenVPN сервер и OpenVPN клиент (шлюз) в нужную мне конфигурацию, таким образом в случае необходимости создание новой пары шлюз-сервер занимает автоматом до 5 минут)
· предварительную платформу для связи (каждый скайп, sip телефон, jabber работает с своего IP и сводится в одну точку )
· OS с которой хочешь работать — какую поставишь, такая и будет
· нет ничего лишнего на компьютере с которого работаешь
· доступ по умолчанию закрыт и открываешь по необходимости
· возможность коллективной работы.
Список можно продолжать долго и ограничивается только фантазией.
