• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Миграция старый сервер = новый сервер

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Задача
нужно перекинуть данные со старого сервера на новый - модификация и улучшение железа
оба сервера имеют одну и ту же ID

как правильно сделать переезд при одновременно работающих двоих

Ранее я просто копировал все данные, на файловом уровне а потом просто поднимал новый с IP как у старого

Теперь стало интересно как это сделать не на файловом уровне

Имеем кучу баз, ДАОС и т.д.

Обьединить их в кластер и сделать синхронный кластер не получится, но нужно что-то вроде такого, чтобы они сами с синхронились и позволили всё автоматически разрулить

Идеи?
 

savl

Lotus Team
28.10.2011
2 612
313
BIT
356
а эти сервера одновременно в сети? и нет конфликтов?

можно попробовать закрыть доступ к новому и с клиента пустить реплику, по IP.
Да трафик через клиента пойдет, но это может сработать. Этакий треугольник: Сервер А, Сервера А' и Клиент B.
и все же с подменой IP проще будет, раз ID одна.
 

Pernat1y

Well-known member
05.04.2018
1 443
135
BIT
0
1. Собрать кластер с репликацией из 2х серверов. Иначе онлайн перенести БД не получится.
2. Поднять балансер, который после переноса данных на новый сервер просто переключит клиента туда.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 965
611
BIT
318
взять ZFS, дропнуть соединения на первом (либо стопнуть домину, что надежней, в смысле агентов), снимок, отправить снимок на вторую ноду (синхронизация займет время от размера стораджа, потому первый надо будет держать доступным, время на снимок мало), остановить первый, разностный снимок на вторую ноду (будет быстро), запустить вторую ноду...
ах да - это не для винды ;)
в схеме будет перерыв по доступу, зато синхронность гарантирована, как и имя сервера сохранится
это не файловый уровень, а блочный, работает достаточно быстро
отправка как по сети так и локально, с тз ZFS разницы не будет
пример для локального разностного:
Bash:
 zfs send -I rpool/vm-201-disk-0@2020-08-22_00:28 rpool/vm-201-disk-0@2020-09-18_21:37 | pv | zfs recv tank/vm-201-disk-0
между пайпами вставляем ssh и получаем сеть
от оракля примеры
это работает для ZOL (ZFS on Linux) и proxmox в частности (где ещё есть и HA с общим стораджем)
 
Последнее редактирование:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 965
611
BIT
318
1. Собрать кластер с репликацией из 2х серверов. Иначе онлайн перенести БД не получится.
2. Поднять балансер, который после переноса данных на новый сервер просто переключит клиента туда.
у ХСЛ есть туториалы как держать кластер синхронным по базам (сами будут создаваться и поддерживать рабочее состояние)
балансер для клиента - это делается самим клиентом (если про нотусню)
 

savl

Lotus Team
28.10.2011
2 612
313
BIT
356
Был бы контейнер было бы проще, там считай только бины да настройки. Но я не эксперт.
А так, либо подмена, либо треугольник, только важно чтобы трейс клиента был по ip, ну и реплики гнать именно по ip.
тот же daos не обязательно переносить на ФС-уровне, просто второй сервак во время реплики будет его создавать.
Важен еще момент с шифрованием NLO, но если имя одно и id одна, то теоретически можно перенести и на ФС-уровне.

Хотя все же теоретически... оба сервера онлайн.. а работа сразу на двоих будет идти?
я к тому, что можно поднять второй сервер с минимальными задачами: выключить все что только можно.
потом на уровне ФС перенести данные, которые нужны.
Domino штука забавная, она позволяет на лету добавлять базы в Data, можно даже не в Data + Folder/db Link, будут ли они сразу доступны - не скажу, но скорее всего будет некий лаг.
отдельный момент с логами транзакций.. как они себя поведут.
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
9
тоже вариант :)
но палюбому даунтайм
Всегда без даунтайма обходится с кластером, забывая навсегда имя сервера:) хотя не - помню была серия из Basra, Mosul, Falludgi...
Не понятна сама привязка к имени сервера, которая ведёт к проблемам переноса...
 

zakrush

Well-known member
21.03.2018
81
118
BIT
0
Мы когда то держали резервный сервер на случай отказа основного (горячий резерв). Так реализовано было следующим образом:
1. Базы на реплике.
2. Остальные необходимые данные на rsync.

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

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 965
611
BIT
318
Мы когда то держали резервный сервер на случай отказа основного (горячий резерв). Так реализовано было следующим образом:
1. Базы на реплике.
2. Остальные необходимые данные на rsync.

Второй резервный сервер естественно предварительно настроен как надо.
На основном сервере стопаришь коннекты к базе, ждешь пока слейв догонит мастера, переключаешь их местами.
Далее весь трафик с основного сервера перегоняешь на новый(например на уровне nginx). (Это если ИП поменялся и DNS пока еще не обновились). Потом, когда все норм и страбилизировалось, убираешь старый сервер.
Схема проста до не возможности. И даунтайм минимальный.
Плюс схемы, в том, что если пошло не так, можно быстро откатиться.
Из советов: когда будешь делать трюки в конфигах(например в nginx) бэкапься. Самое простое гитом.
ну это есть прокмокс HA называется, ток полку надо (общий сторадж), или реплики ФС (но там заморочится с остановкой домины надо)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!