Урадите сами Баре-Метал Провисионинг, или аутоматска припрема сервера од нуле

Здраво, ја сам Денис и једна од мојих делатности је развој инфраструктурних решења у компанији Кс5. Данас бих желео да поделим са вама како можете да примените систем за аутоматску припрему сервера заснован на јавно доступним алатима. По мом мишљењу, ово је занимљиво, једноставно и флексибилно решење.

Под припремом подразумевамо: претворите нови сервер из кутије у потпуно конфигурисан сервер са оперативним системом. Линук или са ЕСКСи хипервизором (у овом чланку се не говори о постављању Виндовс сервера).

Услови:

• сервери – сервери које треба конфигурисати.
• инсталациони сервер је главни сервер који обезбеђује цео процес припреме преко мреже.

Зашто је потребна аутоматизација?

Рецимо да постоји задатак: масовно припремити сервере од нуле, на врхунцу - 30 дневно. На њима могу бити инсталирани сервери различитих произвођача и модела, различити оперативни системи, а могу и не морају имати хипервизор.

Које операције су укључене у процес подешавања (без аутоматизације):

• повежите тастатуру, миш, монитор на сервер;
• конфигуришите БИОС, РАИД, ИПМИ;
• ажурирање фирмвера компоненте;
• примените слику система датотека (или инсталирајте хипервизор и копирајте виртуелне машине);

Белешка. Алтернативно, имплементација ОС-а је могућа кроз инсталацију са датотеком аутоматског одговора. Али о томе се неће говорити у чланку. Иако ћете у наставку видети да додавање ове функционалности није тешко.

• конфигуришите параметре ОС (име хоста, ИП, итд.).

Са овим приступом, иста подешавања се обављају узастопно на сваком серверу. Ефикасност таквог рада је веома ниска.

Суштина аутоматизације је да се елиминише људско учешће из процеса припреме сервера. Колико год је могуће.

Аутоматизација смањује време застоја између операција и омогућава обезбеђивање више сервера истовремено. Вероватноћа грешака услед људског фактора је такође значајно смањена.

Како се сервери аутоматски конфигуришу?

Хајде да детаљно анализирамо све фазе.

Имате Линук сервер који користите као ПКСЕ инсталациони сервер. На њему су инсталирани и конфигурисани сервиси: ДХЦП, ТФТП.

Дакле, покрећемо сервер (који треба да се конфигурише) преко ПКСЕ. Подсетимо се како то функционише:

• Мрежно покретање је изабрано на серверу.
• Сервер учитава ПКСЕ-РОМ мрежне картице и контактира инсталациони сервер преко ДХЦП-а да би добио мрежну адресу.
• ДХЦП инсталациони сервер издаје адресу, као и упутства за даље преузимање путем ПКСЕ.
• Сервер учитава мрежни боотлоадер са инсталационог сервера преко ПКСЕ, даље учитавање се дешава према ПКСЕ конфигурационој датотеци.
• Покретање се дешава на основу примљених параметара (кернел, инитрамфс, тачке монтирања, скуасхфс слика, итд.).

Белешка. Чланак описује покретање преко ПКСЕ преко БИОС режима. Тренутно, произвођачи активно имплементирају УЕФИ режим покретања. За ПКСЕ, разлика ће бити у конфигурацији ДХЦП сервера и присуству додатног покретача.

Погледајмо пример конфигурације ПКСЕ сервера (пкелинук мени).

Датотека пкелинук.цфг/дефаулт:

default menu.c32
prompt 0
timeout 100
menu title X5 PXE Boot Menu
LABEL InstallServer Menu
	MENU LABEL InstallServer
	KERNEL menu.c32
	APPEND pxelinux.cfg/installserver
LABEL VMware Menu
	MENU LABEL VMware ESXi Install
	KERNEL menu.c32
	APPEND pxelinux.cfg/vmware
LABEL toolkit // меню по умолчанию
	MENU LABEL Linux Scripting Toolkits
	MENU default
	KERNEL menu.c32
	APPEND pxelinux.cfg/toolkit // переход на следующее меню

Датотека пкелинук.цфг/тоолкит:

prompt 0
timeout 100
menu title X5 PXE Boot Menu
label mainmenu
    menu label ^Return to Main Menu
    kernel menu.c32
    append pxelinux.cfg/default
label x5toolkit-auto // по умолчанию — автоматический режим
        menu label x5 toolkit autoinstall
        menu default
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tk-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh CMDIS2=”…”
label x5toolkit-shell // для отладки - консоль
        menu label x5 toolkit shell
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tkcustom-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash CMDIS2=”…”

Кернел и инитрамфс у овој фази су средња Линукс слика, уз помоћ које ће се одвијати главна припрема и конфигурација сервера.

Као што видите, покретач преноси многе параметре кернелу. Неке од ових параметара користи само језгро. А неке можемо искористити за своје потребе. О томе ће бити речи касније, али за сада можете само да запамтите да ће сви прослеђени параметри бити доступни у средњој Линук слици преко /проц/цмдлине.

Где могу да их набавим, кернел и инитрамфс?
Као основу, можете одабрати било коју дистрибуцију Линука. На шта обраћамо пажњу при избору:

• слика за покретање мора бити универзална (доступност драјвера, могућност инсталирања додатних услужних програма);
• Највероватније ћете морати да прилагодите инитрамфс.

Како се то ради у нашем решењу за Кс5? За основу је изабран ЦентОС 7. Хајде да испробамо следећи трик: припремимо будућу структуру слике, спакујемо је у архиву и креирамо инитрамф, унутар којег ће се налазити архива нашег система датотека. Приликом учитавања слике, архива ће бити проширена у креирану тмпфс партицију. На овај начин ћемо добити минималну, али пуноправну ливе линук слику са свим потребним услужним програмима, која се састоји од само два фајла: вмкернел и инитрамфс.

#создаем директории: 

mkdir -p /tftpboot/toolkit/CustomTK/rootfs /tftpboot/toolkit/CustomTK/initramfs/bin

#подготавливаем структуру:

yum groups -y install "Minimal Install" --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y install nfs-utils mariadb ntpdate mtools syslinux mdadm tbb libgomp efibootmgr dosfstools net-tools pciutils openssl make ipmitool OpenIPMI-modalias rng-tools --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y remove biosdevname --installroot=/tftpboot/toolkit/CustomTK/rootfs/

# подготавливаем initramfs:

wget https://busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-x86_64 -O /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
chmod a+x /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
cp /tftpboot/toolkit/CustomTK/rootfs/boot/vmlinuz-3.10.0-957.el7.x86_64 /tftpboot/toolkit/tkcustom-kernel

# создаем /tftpboot/toolkit/CustomTK/initramfs/init (ниже содержание скрипта):

#!/bin/busybox sh
/bin/busybox --install /bin
mkdir -p /dev /proc /sys /var/run /newroot
mount -t proc proc /proc
mount -o mode=0755 -t devtmpfs devtmpfs /dev
mkdir -p /dev/pts /dev/shm /dev/mapper /dev/vc
mount -t devpts -o gid=5,mode=620 devpts /dev/pts
mount -t sysfs sysfs /sys
mount -t tmpfs -o size=4000m tmpfs /newroot
echo -n "Extracting rootfs... "
xz -d -c -f rootfs.tar.xz | tar -x -f - -C /newroot
echo "done"
mkdir -p /newroot/dev /newroot/proc /newroot/sys
mount --move /sys  /newroot/sys
mount --move /proc /newroot/proc
mount --move /dev  /newroot/dev
exec switch_root /newroot /sbin/init

# упаковываем rootfs и initramfs:

cd /tftpboot/toolkit/CustomTK/rootfs
tar cJf /tftpboot/toolkit/CustomTK/initramfs/rootfs.tar.xz --exclude ./proc --exclude ./sys --exclude ./dev .
cd /tftpboot/toolkit/CustomTK/initramfs
find . -print0 | cpio --null -ov --format=newc | gzip -9 > /tftpboot/toolkit/tkcustom-initramfs-new.gz

Дакле, навели смо кернел и инитрамфс који треба да се учитају. Као резултат тога, у овој фази, учитавањем средње линукс слике преко ПКСЕ, добићемо ОС конзолу.

Одлично, али сада морамо да пренесемо контролу на нашу „аутоматизацију“.

Може се овако.

Претпоставимо да након учитавања слике планирамо да пренесемо контролу на моунт.сх скрипту.
Хајде да укључимо моунт.сх скрипту у ауторун. Да бисте то урадили, мораћете да измените инитрамфс:

• распакујте инитрамфс (ако користимо горњу опцију инитрамфс, ово није потребно)
• укључити код у покретању који ће анализирати параметре пропуштене кроз /проц/цмдлине и даље контролу преноса;
• пацк инитрамфс.

Белешка. У случају Кс5 алата, контрола учитавања се преноси на скрипту /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Дакле, слика је учитана, у којој скрипта моунт.сх почиње при аутоматском покретању. Затим, моунт.сх скрипта анализира прослеђене параметре (сцрипт_цмд=) током извршавања и покреће неопходан програм/скрипту.

сет алата за етикете-ауто
кернел...
додај... нфс_тоолкит_сцрипт=сцриптс/моунт.сх сцрипт_цмд=мастер-инсталл.сх

сет алата за етикете-граната
кернел...
додај... нфс_тоолкит_сцрипт=сцриптс/моунт.сх сцрипт_цмд=/бин/басх

Овде са леве стране је ПКСЕ мени, са десне стране је дијаграм преноса контроле.

Схватили смо пренос контроле. У зависности од избора ПКСЕ менија, покреће се или скрипта за аутоматску конфигурацију или конзола за отклањање грешака.

У случају аутоматске конфигурације, са инсталационог сервера се монтирају потребни директоријуми који садрже:

• скрипте;
• сачувани БИОС/УЕФИ шаблони за различите сервере;
• фирмвер;
• серверски услужни програми;
• трупаца

Затим, моунт.сх скрипта преноси контролу на мастер-инсталл.сх скрипту из директоријума скрипте.

Стабло скрипте (редослед којим се покрећу) изгледа отприлике овако:

• мастер-инсталл
• схарефунцтионс (заједничке функције)
• инфо (излаз информација)
• модели (подешавање параметара инсталације на основу модела сервера)
• припреми_утилс (инсталација потребних услужних програма)
• фвупдате (ажурирање фирмвера)
• дијагноза (елементарна дијагностика)
• биосцонф (БИОС/УЕФИ подешавања)
• исправка сата (подешавање времена на матичној плочи)
• срмцонф (конфигурација интерфејса удаљеног интерфејса)
• раидцонф (конфигурисање логичких волумена)

један од:

• унапред инсталирање (пренос контроле на ОС или инсталатер хипервизора, као што је ЕСКСи)
• мергед-инсталл (тренутни почетак распакивања слике)

Сада знамо:

• како покренути сервер преко ПКСЕ;
• како да пренесете контролу на сопствену скрипту.

Наставимо. Следећа питања су постала релевантна:

• Како да идентификујемо сервер који припремамо?
• Који услужни програми и како конфигурисати сервер?
• Како добити подешавања за одређени сервер?

Како да идентификујемо сервер који припремамо?

Једноставно је - ДМИ:

dmidecode –s system-product-name
dmidecode –s system-manufacturer
dmidecode –s system-serial-number

Овде је све што вам треба: продавац, модел, серијски број. Ако нисте сигурни да су ове информације присутне на свим серверима, можете их идентификовати по њиховој МАЦ адреси. Или на оба начина у исто време, ако су добављачи сервера различити и на неким моделима једноставно нема информација о серијском броју.

На основу добијених информација, са инсталационог сервера се монтирају мрежне фасцикле и учитава се све што је потребно (услужни програми, фирмвер итд.).

Који услужни програми и како конфигурисати сервер?

Обезбедићу услужне програме за Линук за неке произвођаче. Сви услужни програми доступни су на званичним веб локацијама добављача.

Са фирмвером, мислим да је све јасно. Обично долазе у облику упакованих извршних датотека. Извршна датотека контролише процес ажурирања фирмвера и извештава о повратном коду.

БИОС и ИПМИ се обично конфигуришу преко шаблона. Ако је потребно, шаблон се може уредити пре преузимања.

РАИД услужни програми неких произвођача такође се могу конфигурисати помоћу шаблона. Ако то није случај, мораћете да напишете конфигурациону скрипту.

Процедура за подешавање РАИД-а најчешће је следећа:

• Захтевамо тренутну конфигурацију.
• Ако већ постоје логички низови, бришемо их.
• Хајде да погледамо који су физички дискови присутни и колико их има.
• Креирајте нови логички низ. Прекидамо процес у случају грешке.

Како добити подешавања за одређени сервер?

Претпоставимо да ће подешавања свих сервера бити сачувана на инсталационом серверу. У овом случају, да бисмо одговорили на наше питање, прво морамо одлучити како да пренесемо подешавања на инсталациони сервер.

У почетку се можете снаћи са текстуалним датотекама. (У будућности ћете можда желети да користите текстуалну датотеку као резервни метод за пренос подешавања.)

Можете „делити“ текстуалну датотеку на инсталационом серверу. И додајте његов моунт у моунт.сх скрипту.

Линије ће, на пример, изгледати овако:

<серијски број> <име хоста> <подмрежа>

Ове линије ће инжењер пренети у фајл са своје радне машине. А затим, приликом подешавања сервера, параметри за одређени сервер ће бити прочитани из датотеке.

Али, дугорочно гледано, боље је користити базу података за чување подешавања, стања и евиденције инсталација сервера.

Наравно, сама база података није довољна, већ ћете морати да креирате клијентски део уз помоћ којег ће се подешавања пренети у базу података. Ово је теже имплементирати у поређењу са текстуалном датотеком, али у ствари, све није тако тешко као што се чини. Сасвим је могуће написати минималну верзију клијента који ће једноставно сами пренети податке у базу података. А у будућности ће бити могуће побољшати клијентски програм у бесплатном режиму (извештаји, штампање етикета, слање обавештења, итд. што вам падне на памет).

Постављањем конкретног захтева бази података и навођењем серијског броја сервера, добићемо потребне параметре за конфигурисање сервера.

Осим тога, нећемо морати да смислимо браве за истовремени приступ, као што је случај са текстуалном датотеком.

Можемо да упишемо дневник конфигурације у базу података у свим фазама и да контролишемо процес инсталације кроз догађаје и ознаке фаза припреме.

Сада знамо како:

• покрените сервер преко ПКСЕ;
• пренесите контролу на нашу скрипту;
• идентификују сервер који треба да се припреми по његовом серијском броју;
• конфигуришите сервер користећи одговарајуће услужне програме;
• пренети подешавања у базу података инсталационог сервера користећи клијентски део.

Сазнали смо како:

• инсталирани сервер прима потребна подешавања из базе података;
• сав напредак припреме се бележи у бази података (логови, догађаји, сценске заставице).

Шта је са различитим типовима софтвера које инсталирате? Како инсталирати хипервизор, копирати ВМ и све то конфигурисати?

У случају постављања слике система датотека (линукс) на хардвер, све је прилично једноставно:

• Након подешавања свих компоненти сервера, постављамо слику.
• Инсталирајте груб боотлоадер.
• Ми цхроот и конфигуришемо све што је потребно.

Како пренети контролу на инсталатер ОС-а (користећи ЕСКСи као пример).

• Организујемо пренос контроле са наше скрипте на инсталатер хипервизора користећи аутоматски одговор (кицкстарт):
• Бришемо тренутне партиције на диску.
• Направите партицију величине 500МБ.
• Означавамо га као могућност покретања.
• Форматирајте у ФАТ32.
• Копирамо ЕСКСи инсталационе датотеке у роот.
• Инсталирање сислинук-а.
• Копирајте сислинук.цфг у /сислинук/

default esxi
prompt 1
timeout 50
label esxi
kernel mboot.c32
append -c boot.cfg

• Копирајте боот.ц32 у /сислинук.
• Боот.цфг треба да има кернелопт=кс=фтп:// /кс_ески.цфг
• Поново покрећемо сервер.

Након што се сервер поново покрене, ЕСКСи инсталатер ће преузети са хард диска сервера. Све неопходне инсталационе датотеке ће бити учитане у меморију и тада ће ЕСКСи инсталација почети, у складу са наведеном датотеком аутоматског одговора.

Ево неколико редова из датотеке аутоматског одговора кс_ески.цфг:

%firstboot --interpreter=busybox
…
# получаем серийный номер

SYSSN=$(esxcli hardware platform get | grep Serial | awk -F " " '{print $3}')

# получаем IP

IPADDRT=$(esxcli network ip interface ipv4 get | grep vmk0 | awk -F " " '{print $2}')
LAST_OCTET=$(echo $IPADDRT | awk -F'.' '{print $4}')

# подключаем NFS инсталл-сервера

esxcli storage nfs add -H is -s /srv/nfs_share -v nfsshare1

# копируем временные настройки ssh, для использования ssh-клиента

mv /etc/ssh /etc/ssh.tmp
cp -R /vmfs/volumes/nfsshare1/ssh /etc/
chmod go-r /etc/ssh/ssh_host_rsa_key

# копируем ovftool, для развертывания ВМ сейчас, плюс возможно пригодится позже

cp -R /vmfs/volumes/nfsshare1/ovftool /vmfs/volumes/datastore1/

# развертываем ВМ

/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM1 /vmfs/volumes/nfsshare1/VM_T/VM1.ova vi://root:[email protected]
/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM2 /vmfs/volumes/nfsshare1/VM_T/VM2.ova vi://root:[email protected]

# получаем строку с настройками нашего сервера

ssh root@is "mysql -h'192.168.0.1' -D'servers' -u'user' -p'secretpassword' -e "SELECT ... WHERE servers.serial='$SYSSN'"" | grep -v ^$ | sed 's/NULL//g' > /tmp/servers
...
# генерируем скрипт настройки сети

echo '#!/bin/sh' > /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip interface ipv4 set -i=vmk0 -t=static --ipv4=$IPADDR --netmask=$S_SUB || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip route ipv4 add -g=$S_GW -n=default || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
chmod a+x /vmfs/volumes/datastore1/netconf.sh

# задаем параметр guestinfo.esxihost.id, указываем в нем серийный номер

echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM1/VM1.vmx
echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM2/VM2.vmx
...
# обновляем информацию в базе

SYSNAME=$(esxcli hardware platform get | grep Product | sed 's/Product Name://' | sed 's/^ *//')
UUID=$(vim-cmd hostsvc/hostsummary | grep uuid | sed 's/ //g;s/,$//' | sed 's/^uuid="//;s/"$//')
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "UPDATE servers ... SET ... WHERE servers.serial='$SYSSN'""
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "INSERT INTO events ...""

# возвращаем настройки SSH

rm -rf /etc/ssh
mv /etc/ssh.tmp /etc/ssh

# настраиваем сеть и перезагружаемся

esxcli system hostname set --fqdn=esx-${G_NICK}.x5.ru
/vmfs/volumes/datastore1/netconf.sh
reboot

У овој фази, хипервизор се инсталира и конфигурише, а виртуелне машине се копирају.

Како сада конфигурисати виртуелне машине?

Мало смо се преварили: током инсталације поставили смо параметар гуестинфо.ескихост.ид = "$СИССН" у ВМ1.вмк датотеци и назначили серијски број физичког сервера у њему.

Сада, након покретања, виртуелна машина (са инсталираним пакетом вмваре-тоолс) може да приступи овом параметру:

ESXI_SN=$(vmtoolsd --cmd "info-get guestinfo.esxihost.id")

То јест, ВМ ће моћи да се идентификује (зна серијски број физичког хоста), да упути захтев бази података инсталационог сервера и добије параметре које треба конфигурисати. Све ово је састављено у скрипту, која би требало да се покрене аутоматски када се гуестос вм покрене (али једном: РунОнце).

Сада знамо како:

• покрените сервер преко ПКСЕ;
• пренесите контролу на нашу скрипту;
• идентификују сервер који треба да се припреми по његовом серијском броју;
• конфигуришите сервер користећи одговарајуће услужне програме;
• пренесите подешавања у базу података инсталационог сервера користећи клијентски део;
• конфигурисање различитих типова софтвера, укључујући примену ески хипервизора и конфигурисање виртуелних машина (све аутоматски).

Сазнали смо како:

• инсталирани сервер прима потребна подешавања из базе података;
• сав напредак припреме се бележи у бази података (логови, догађаји, сценске заставице).

Доња линија:

Верујем да је јединственост овог решења у његовој флексибилности, једноставности, могућностима и свестраности.

Напишите у коментарима шта мислите.

Извор: ввв.хабр.цом