Апгрейд с wheezy на stretch (2x до 3х) » История » Версия 18
Версия 17 (Владимир Ипатов, 19.01.2020 21:17) → Версия 18/35 (Владимир Ипатов, 19.01.2020 21:20)
h1. Апгрейд с wheezy на stretch (2.x до 3.х)
Данный апгрейд может проводиться с минимальным простоем, т.к. внутри одного кластера могут успешно работать узлы версии 2.х и 3.х, в том числе работает репликация DRBD между узлами версии 2.х и 3.х
В случае Linux виртуальных машин требуется только одна перезагрузка при переносе с 2.x узла на 3.х узла.
В случае Windows виртуальных машин иногда требуется однократная загрузка в безопасном режиме и/или заход под пользователем в локальную консоль виртуальной машины для установки "нового" эмулируемого диска и сетевой карты.
h2. Общая процедура апгрейда
1) обновляются все резервные узлы кластера. Это можно сделать обновлением дистрибутива (см. выше) или переустановкой узлов с нуля. Переустановка узлов с нуля - менее сложный процесс, но более длительный, т.к. придется заново ресинкать все тома всех виртуальных машин.
2) после обновления всех резервных узлов делаются настройки кластера, позволяющие работать в смешанном окружении. Смешанный кластер до момента перенастройки не может выполнять операции по старту/остановке виртуальных машин, их переносу, перенастройке и т.д.
3) все виртуальные машины переносятся на резервные узлы, их проверяется работоспособность.
4) обновляются узлы второй половины кластера.
h2. Апгрейд узла
Для апгрейда узла два способа:
1) Переустановка узла (легкий, но долгий путь, требует ресинка дрбд на всех виртуальных машинах)
2) Обновление пакетов (трудоемкий путь, но позволяет быстрее выполнить миграцию, не требует ресинка дрбд)
h3. Переустановка узла
Для апгрейда с переустановкой узла требуется:
1) сохранить содержимое файла /etc/network/interfaces и /etc/hostname на обновляемом узле
2) загрузиться с флешки/диска и установить на обновляемый узел SkyCover 3.x. При этом нужно при установке ввести такой же lan ip, хостнейм, домен, какой был. подробнее: [[УСТАНОВКА]]
3) настроить конфиг сетевых интерфейсов /etc/network/interfaces, используя сохраненное содержимое, перезапустить сеть с помощью service networking restart.
4) порядок сетевых интерфейсов мог поменяться, проверить пинг до мастера через backbone, lan и т.д. Если что-то не совпадает, то, отключая кабель по одному сетевому интерфейсу и запуска ip link show (показывает, где нет линка) идентифицировать сетевые интерфейсы и переназначить их в /etc/network/interfaces, перезапустить сеть
5) с мастера выполнить команды:
<pre>
gnt-node add --readd ХОСТНЕЙМ
gnt-cluster redist-conf
</pre>
h3. Обновление пакетов
Обновление пакетов идет в 2 приема. с Wheezy на Jessie, с Jessie на Stretch.
После обновления с Wheezy на Jessie узел будет в неработособном состоянии, так что оба обновления нужно делать сразу один за другим.
Отключаем puppet:
service puppet stop
в /etc/default/puppet прописываем START=no
Перенастраиваем apt:
меняем содержимое /etc/apt/sources.list.
было:
<pre>
#
# stable
#
deb http://archive.debian.org/debian wheezy main
deb http://archive.debian.org/debian-security wheezy/updates main
#
# backports
#
deb http://archive.debian.org/debian/ wheezy-backports main
</pre>
стало:
<pre>
#
# stable
#
deb http://archive.debian.org/debian jessie main
deb http://archive.debian.org/debian-security jessie/updates main
#
# backports
#
deb http://archive.debian.org/debian/ jessie-backports main
</pre>
меняем содержимое /etc/apt/apt.conf.d/99stable
<pre>
APT::Default-Release "jessie";
</pre>
меняем содержимое /etc/apt/sources.list.d/sci-dev.list
<pre>
deb http://sci-dev.skycover.ru/apt stretch main
</pre>
скачиваем и устанавливаем новый ключ для sci-dev:
<pre>
wget -O- http://sci-dev.skycover.ru/apt/stretch.pub|apt-key add -
</pre>
добавляем новый файл /etc/apt/apt.conf.d/10ignore-expired-release
<pre>
Acquire::Check-Valid-Until "0";
</pre>
делаем aptitude update
делаем aptitude full-upgrade
После успешного апгрейда перезагружаемся.
Перенастраиваем apt еще раз
/etc/apt/sources.list:
<pre>
deb http://ftp.debian.org/debian stretch main contrib non-free
deb http://ftp.debian.org/debian stretch-updates main contrib non-free
deb http://ftp.debian.org/debian stretch-backports main contrib non-free
</pre>
/etc/apt/apt.conf.d/99stable:
<pre>
APT::Default-Release "stretch";
</pre>
обновляемся до stretch:
aptitude update
aptitude full-upgrade
перезагрузка
проверяем версии пакетов:
dpkg -l|grep ganeti - должны быть 2.15-sciX, instance-debootstrap должн быть 0-16-sciX
если версси несовпадают, обновить из репозитория sci-dev.skycover.ru/apt
если в процессе обновления qemu и qemu-system остались в версии wheezy, то следует их обновить руками:
aptitude install qemu qemu-system
если xen 4.8 не установился сам ,то нужно установить руками:
<pre>
sudo aptitude install xen-hypervisor-4.8-amd64 xen-utils-4.8
</pre>
удалить systemd:
<pre>
apt-get install -y --force-yes sysvinit-core sysvinit-utils
cp /usr/share/sysvinit/inittab /etc/inittab
перезагрузка
apt-get remove -y --force-yes --purge --auto-remove systemd
echo -e 'Package: systemd\nPin: release *\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
echo -e '\n\nPackage: *systemd*\nPin: release *\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
echo -e '\nPackage: systemd:i386\nPin: release *\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
</pre>
настраиваем ssh на работу с dss ключами:
/etc/ssh/sshd_config:
<pre>
PubkeyAcceptedKeyTypes=+ssh-dss
</pre>
/etc/ssh/ssh_config:
<pre>
PubkeyAcceptedKeyTypes=+ssh-dss
</pre>
(отступ должен быть сохранен)
service ssh restart
на каждом узле должен быть файл /var/lib/ganeti/rapi/users
<pre>
scweb СЛУЧАЙНЫЙ_ПАРОЛЬ write
</pre>
переинициализируем паппет:
<pre>
rm -r /var/lib/puppet/ssl
в /etc/default/puppet START=yes
puppet agent --enable
</pre>
также в конфиг следует указать новый паппет мастер для новых паппет агентов, т.к. паппетмастер в wheezy не совместим с агентами stretch.
удаляем локальные скрипты старых версий:
rm /usr/local/sbin/*
устанавливаем доп пакеты sci:
aptitude install sci-web sci-config sci-scripts sci-udev-netrules
h2. Перенастройка кластера для работы в смешанном окружении.
Смешанный кластер до момента перенастройки не может выполнять операции по старту/остановке виртуальных машин, их переносу, перенастройке и т.д.
Суть настроек заключается в том, что в узлах версии 3 больше нет toolstack xm, есть только xl. Поэтому нужно перенастроить все узлы и кластер на использование xl.
Также в узлах версии 2.х и 3.х несовпадают некоторые пути, это решается за счет симлинков
h3. добавление симлинков
на каждом узле 2.x:
<pre>
ln -s /usr/lib/xen-4.1 /usr/lib/xen
ln -s /usr/lib/xen/bin/qemu-dm /usr/bin/qemu-system-x86_64
</pre>
h3. перенастройка кластера на xl
на каждом узле 2.х:
в /etc/xen/xl.conf установить autoballoon=0
в /etc/default/xen установить TOOLSTACK=xl
service xen restart
на мастере:
перенастройка кластера на новые пути:
<pre>
gnt-cluster modify -H xen-pvm:bootloader_path=/usr/lib/xen/bin/pygrub
gnt-cluster modify -H xen-pvm:initrd_path=/boot/initrd.img-xenU
gnt-cluster modify -H xen-pvm:kernel_path=/boot/vmlinuz-xenU
gnt-cluster modify -H xen-hvm:device_model=/usr/bin/qemu-system-x86_64
gnt-cluster modify -H xen-hvm:kernel_path=/usr/lib/xen/boot/hvmloader
gnt-cluster modify -H xen-pvm:xen_cmd=xl
gnt-cluster modify -H xen-hvm:xen_cmd=xl
</pre>
после всех настроек запустиьт gnt-cluster verify и устранить оставшиеся проблемы.
h2. перенос виртуальных машин
перенос следует делать по одной машине, с проверкой работоспособности
1) произвести failover виртуальной машины:
<pre>
gnt-instance failover МАШИНА
</pre>
2) проверить работоспособность машины с помощью ping и захода по ssh/rdp
В случае windows иногда требуется зайти через vnc на локальную консоль виртуальной машины и однократно либо залогиниться юзером, либо зайти в безопасный режим. После чего перезагрузить систему как обычно.
h2. апгрейд второй половины кластера
для апгрейда второй половины кластера следует повторить операцию апгрейда узла для оставшихся узлов версии 2.x (процедуру см. выше)
Данный апгрейд может проводиться с минимальным простоем, т.к. внутри одного кластера могут успешно работать узлы версии 2.х и 3.х, в том числе работает репликация DRBD между узлами версии 2.х и 3.х
В случае Linux виртуальных машин требуется только одна перезагрузка при переносе с 2.x узла на 3.х узла.
В случае Windows виртуальных машин иногда требуется однократная загрузка в безопасном режиме и/или заход под пользователем в локальную консоль виртуальной машины для установки "нового" эмулируемого диска и сетевой карты.
h2. Общая процедура апгрейда
1) обновляются все резервные узлы кластера. Это можно сделать обновлением дистрибутива (см. выше) или переустановкой узлов с нуля. Переустановка узлов с нуля - менее сложный процесс, но более длительный, т.к. придется заново ресинкать все тома всех виртуальных машин.
2) после обновления всех резервных узлов делаются настройки кластера, позволяющие работать в смешанном окружении. Смешанный кластер до момента перенастройки не может выполнять операции по старту/остановке виртуальных машин, их переносу, перенастройке и т.д.
3) все виртуальные машины переносятся на резервные узлы, их проверяется работоспособность.
4) обновляются узлы второй половины кластера.
h2. Апгрейд узла
Для апгрейда узла два способа:
1) Переустановка узла (легкий, но долгий путь, требует ресинка дрбд на всех виртуальных машинах)
2) Обновление пакетов (трудоемкий путь, но позволяет быстрее выполнить миграцию, не требует ресинка дрбд)
h3. Переустановка узла
Для апгрейда с переустановкой узла требуется:
1) сохранить содержимое файла /etc/network/interfaces и /etc/hostname на обновляемом узле
2) загрузиться с флешки/диска и установить на обновляемый узел SkyCover 3.x. При этом нужно при установке ввести такой же lan ip, хостнейм, домен, какой был. подробнее: [[УСТАНОВКА]]
3) настроить конфиг сетевых интерфейсов /etc/network/interfaces, используя сохраненное содержимое, перезапустить сеть с помощью service networking restart.
4) порядок сетевых интерфейсов мог поменяться, проверить пинг до мастера через backbone, lan и т.д. Если что-то не совпадает, то, отключая кабель по одному сетевому интерфейсу и запуска ip link show (показывает, где нет линка) идентифицировать сетевые интерфейсы и переназначить их в /etc/network/interfaces, перезапустить сеть
5) с мастера выполнить команды:
<pre>
gnt-node add --readd ХОСТНЕЙМ
gnt-cluster redist-conf
</pre>
h3. Обновление пакетов
Обновление пакетов идет в 2 приема. с Wheezy на Jessie, с Jessie на Stretch.
После обновления с Wheezy на Jessie узел будет в неработособном состоянии, так что оба обновления нужно делать сразу один за другим.
Отключаем puppet:
service puppet stop
в /etc/default/puppet прописываем START=no
Перенастраиваем apt:
меняем содержимое /etc/apt/sources.list.
было:
<pre>
#
# stable
#
deb http://archive.debian.org/debian wheezy main
deb http://archive.debian.org/debian-security wheezy/updates main
#
# backports
#
deb http://archive.debian.org/debian/ wheezy-backports main
</pre>
стало:
<pre>
#
# stable
#
deb http://archive.debian.org/debian jessie main
deb http://archive.debian.org/debian-security jessie/updates main
#
# backports
#
deb http://archive.debian.org/debian/ jessie-backports main
</pre>
меняем содержимое /etc/apt/apt.conf.d/99stable
<pre>
APT::Default-Release "jessie";
</pre>
меняем содержимое /etc/apt/sources.list.d/sci-dev.list
<pre>
deb http://sci-dev.skycover.ru/apt stretch main
</pre>
скачиваем и устанавливаем новый ключ для sci-dev:
<pre>
wget -O- http://sci-dev.skycover.ru/apt/stretch.pub|apt-key add -
</pre>
добавляем новый файл /etc/apt/apt.conf.d/10ignore-expired-release
<pre>
Acquire::Check-Valid-Until "0";
</pre>
делаем aptitude update
делаем aptitude full-upgrade
После успешного апгрейда перезагружаемся.
Перенастраиваем apt еще раз
/etc/apt/sources.list:
<pre>
deb http://ftp.debian.org/debian stretch main contrib non-free
deb http://ftp.debian.org/debian stretch-updates main contrib non-free
deb http://ftp.debian.org/debian stretch-backports main contrib non-free
</pre>
/etc/apt/apt.conf.d/99stable:
<pre>
APT::Default-Release "stretch";
</pre>
обновляемся до stretch:
aptitude update
aptitude full-upgrade
перезагрузка
проверяем версии пакетов:
dpkg -l|grep ganeti - должны быть 2.15-sciX, instance-debootstrap должн быть 0-16-sciX
если версси несовпадают, обновить из репозитория sci-dev.skycover.ru/apt
если в процессе обновления qemu и qemu-system остались в версии wheezy, то следует их обновить руками:
aptitude install qemu qemu-system
если xen 4.8 не установился сам ,то нужно установить руками:
<pre>
sudo aptitude install xen-hypervisor-4.8-amd64 xen-utils-4.8
</pre>
удалить systemd:
<pre>
apt-get install -y --force-yes sysvinit-core sysvinit-utils
cp /usr/share/sysvinit/inittab /etc/inittab
перезагрузка
apt-get remove -y --force-yes --purge --auto-remove systemd
echo -e 'Package: systemd\nPin: release *\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
echo -e '\n\nPackage: *systemd*\nPin: release *\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
echo -e '\nPackage: systemd:i386\nPin: release *\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
</pre>
настраиваем ssh на работу с dss ключами:
/etc/ssh/sshd_config:
<pre>
PubkeyAcceptedKeyTypes=+ssh-dss
</pre>
/etc/ssh/ssh_config:
<pre>
PubkeyAcceptedKeyTypes=+ssh-dss
</pre>
(отступ должен быть сохранен)
service ssh restart
на каждом узле должен быть файл /var/lib/ganeti/rapi/users
<pre>
scweb СЛУЧАЙНЫЙ_ПАРОЛЬ write
</pre>
переинициализируем паппет:
<pre>
rm -r /var/lib/puppet/ssl
в /etc/default/puppet START=yes
puppet agent --enable
</pre>
также в конфиг следует указать новый паппет мастер для новых паппет агентов, т.к. паппетмастер в wheezy не совместим с агентами stretch.
удаляем локальные скрипты старых версий:
rm /usr/local/sbin/*
устанавливаем доп пакеты sci:
aptitude install sci-web sci-config sci-scripts sci-udev-netrules
h2. Перенастройка кластера для работы в смешанном окружении.
Смешанный кластер до момента перенастройки не может выполнять операции по старту/остановке виртуальных машин, их переносу, перенастройке и т.д.
Суть настроек заключается в том, что в узлах версии 3 больше нет toolstack xm, есть только xl. Поэтому нужно перенастроить все узлы и кластер на использование xl.
Также в узлах версии 2.х и 3.х несовпадают некоторые пути, это решается за счет симлинков
h3. добавление симлинков
на каждом узле 2.x:
<pre>
ln -s /usr/lib/xen-4.1 /usr/lib/xen
ln -s /usr/lib/xen/bin/qemu-dm /usr/bin/qemu-system-x86_64
</pre>
h3. перенастройка кластера на xl
на каждом узле 2.х:
в /etc/xen/xl.conf установить autoballoon=0
в /etc/default/xen установить TOOLSTACK=xl
service xen restart
на мастере:
перенастройка кластера на новые пути:
<pre>
gnt-cluster modify -H xen-pvm:bootloader_path=/usr/lib/xen/bin/pygrub
gnt-cluster modify -H xen-pvm:initrd_path=/boot/initrd.img-xenU
gnt-cluster modify -H xen-pvm:kernel_path=/boot/vmlinuz-xenU
gnt-cluster modify -H xen-hvm:device_model=/usr/bin/qemu-system-x86_64
gnt-cluster modify -H xen-hvm:kernel_path=/usr/lib/xen/boot/hvmloader
gnt-cluster modify -H xen-pvm:xen_cmd=xl
gnt-cluster modify -H xen-hvm:xen_cmd=xl
</pre>
после всех настроек запустиьт gnt-cluster verify и устранить оставшиеся проблемы.
h2. перенос виртуальных машин
перенос следует делать по одной машине, с проверкой работоспособности
1) произвести failover виртуальной машины:
<pre>
gnt-instance failover МАШИНА
</pre>
2) проверить работоспособность машины с помощью ping и захода по ssh/rdp
В случае windows иногда требуется зайти через vnc на локальную консоль виртуальной машины и однократно либо залогиниться юзером, либо зайти в безопасный режим. После чего перезагрузить систему как обычно.
h2. апгрейд второй половины кластера
для апгрейда второй половины кластера следует повторить операцию апгрейда узла для оставшихся узлов версии 2.x (процедуру см. выше)