ProHoster > Blogs > Administrācija > “dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

“dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

Sveiki, esmu Deniss un viena no manām darbības jomām ir X5 infrastruktūras risinājumu izstrāde. Šodien es vēlētos ar jums pastāstīt, kā jūs varat izvietot automātisku servera sagatavošanas sistēmu, kuras pamatā ir publiski pieejami rīki. Manuprāt, tas ir interesants, vienkāršs un elastīgs risinājums.

“dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

Ar sagatavošanu mēs domājam: pārvērtiet jaunu serveri par pilnībā konfigurētu serveri ar OS. Linux vai ar ESXi hipervizoru (Windows serveru izvietošana šajā rakstā nav apspriesta).

Noteikumi:

  • serveri – serveri, kas jākonfigurē.
  • instalācijas serveris ir galvenais serveris, kas nodrošina visu sagatavošanas procesu tīklā.

Kāpēc ir nepieciešama automatizācija?

Teiksim, ir uzdevums: masveidā sagatavot serverus no nulles, maksimumā - 30 dienā. Tajos var būt instalēti dažādu ražotāju un modeļu serveri, dažādas operētājsistēmas, un tiem var būt un var nebūt hipervizora.

Kādas darbības ir iekļautas iestatīšanas procesā (bez automatizācijas):

  • pievienojiet serverim tastatūru, peli, monitoru;
  • konfigurēt BIOS, RAID, IPMI;
  • atjaunināt komponentu programmaparatūru;
  • izvietot failu sistēmas attēlu (vai instalēt hipervizoru un kopēt virtuālās mašīnas);

Piezīme. Alternatīvi, OS izvietošana ir iespējama, instalējot ar automātiskās atbildes failu. Bet tas netiks apspriests rakstā. Lai gan tālāk redzēsit, ka šīs funkcionalitātes pievienošana nav grūta.

  • konfigurēt OS parametrus (resursdatora nosaukums, IP utt.).

Izmantojot šo pieeju, tie paši iestatījumi tiek veikti secīgi katrā serverī. Šāda darba efektivitāte ir ļoti zema.

Automatizācijas būtība ir izslēgt cilvēku līdzdalību servera sagatavošanas procesā. Cik vien iespējams.

Automatizācija samazina dīkstāves laiku starp darbībām un ļauj nodrošināt vairākus serverus vienlaikus. Arī cilvēcisko faktoru radīto kļūdu iespējamība ir ievērojami samazināta.

“dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

Kā serveri tiek automātiski konfigurēti?

Sīkāk analizēsim visus posmus.

Jums ir Linux serveris, ko izmantojat kā PXE instalācijas serveri. Tajā ir instalēti un konfigurēti pakalpojumi: DHCP, TFTP.

Tātad, mēs sāknējam serveri (kas ir jākonfigurē), izmantojot PXE. Atcerēsimies, kā tas darbojas:

  • Serverī ir atlasīta tīkla sāknēšana.
  • Serveris ielādē tīkla kartes PXE-ROM un sazinās ar instalācijas serveri, izmantojot DHCP, lai iegūtu tīkla adresi.
  • DHCP instalācijas serveris izsniedz adresi, kā arī instrukcijas turpmākai lejupielādei, izmantojot PXE.
  • Serveris ielādē tīkla bootloader no instalācijas servera caur PXE, tālāka ielāde notiek atbilstoši PXE konfigurācijas failam.
  • Sāknēšana notiek, pamatojoties uz saņemtajiem parametriem (kodolu, initramfs, mount points, squashfs attēlu utt.).

Piezīme. Rakstā ir aprakstīta sāknēšana, izmantojot PXE, izmantojot BIOS režīmu. Pašlaik ražotāji aktīvi ievieš UEFI sāknēšanas režīmu. PXE gadījumā atšķirība būs DHCP servera konfigurācijā un papildu sāknēšanas ielādētāja klātbūtnē.

Apskatīsim PXE servera konfigurācijas piemēru (pxelinux izvēlne).

Fails pxelinux.cfg/default:

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 // переход на следующее меню

Fails 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=”…”

Kodols un initramfs šajā posmā ir starpposma Linux attēls, ar kura palīdzību notiks galvenā servera sagatavošana un konfigurēšana.

Kā redzat, sāknēšanas ielādētājs nodod kodolam daudzus parametrus. Dažus no šiem parametriem izmanto pats kodols. Un mēs varam izmantot dažus saviem mērķiem. Tas tiks apspriests vēlāk, taču pagaidām varat atcerēties, ka visi nodotie parametri būs pieejami starpposma Linux attēlā, izmantojot /proc/cmdline.

Kur es varu dabūt tos, kodolu un initramfs?
Kā pamatu jūs varat izvēlēties jebkuru Linux izplatīšanu. Kam mēs pievēršam uzmanību, izvēloties:

  • sāknēšanas attēlam jābūt universālam (draiveru pieejamība, iespēja instalēt papildu utilītas);
  • Visticamāk, jums būs jāpielāgo initramfs.

Kā tas tiek darīts mūsu risinājumā X5? Par pamatu tika izvēlēts CentOS 7. Izmēģināsim šādu triku: sagatavosim topošo attēla struktūru, iesaiņojam to arhīvā un izveidojam initramfs, kura iekšpusē atradīsies mūsu failu sistēmas arhīvs. Ielādējot attēlu, arhīvs tiks izvērsts izveidotajā tmpfs nodalījumā. Tādā veidā mēs iegūsim minimālu, tomēr pilnvērtīgu live linux attēlu ar visām nepieciešamajām utilītprogrammām, kas sastāv tikai no diviem failiem: vmkernel un initramfs. 

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

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

Tāpēc mēs esam norādījuši kodolu un initramfs, kas jāielādē. Rezultātā šajā posmā, ielādējot starpposma linux attēlu caur PXE, mēs saņemsim OS konsoli.

Lieliski, bet tagad mums ir jāpārnes vadība uz mūsu “automatizāciju”.

To var izdarīt šādi.

Pieņemsim, ka pēc attēla ielādes plānojam pārsūtīt vadību uz mount.sh skriptu.
Iekļausim skriptu mount.sh automātiskajā palaišanā. Lai to izdarītu, jums būs jāmaina initramfs:

  • izpakojiet initramfs (ja mēs izmantojam iepriekš minēto initramfs opciju, tas nav nepieciešams)
  • startēšanas laikā iekļaujiet kodu, kas analizēs parametrus, kas nodoti caur /proc/cmdline, un pārsūtīs kontroli tālāk;
  • iepakojums initramfs.

Piezīme. X5 rīkkopas gadījumā ielādes vadība tiek pārsūtīta uz skriptu /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Tātad tiek ielādēts attēls, kurā mount.sh skripts sākas ar automātisko palaišanu. Pēc tam skripts mount.sh izpildes laikā analizē nodotos parametrus (script_cmd=) un palaiž nepieciešamo programmu/skriptu.

etiķetes rīku komplekts-auto
kodols...
pievienot... nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

etiķetes rīku komplekts-apvalks
kodols...
pievienot... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

“dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

Šeit kreisajā pusē ir PXE izvēlne, labajā pusē ir vadības pārsūtīšanas diagramma.

Mēs izdomājām kontroles nodošanu. Atkarībā no PXE izvēlnes izvēles tiek palaists automātiskās konfigurācijas skripts vai atkļūdošanas konsole.

Automātiskās konfigurācijas gadījumā no instalācijas servera tiek uzstādīti nepieciešamie direktoriji, kas satur:

  • skripti;
  • saglabātas BIOS/UEFI veidnes dažādiem serveriem;
  • programmaparatūra;
  • serveru utilītas;
  • baļķi

Pēc tam skripts mount.sh no skriptu direktorijas pārsūta kontroli uz skriptu master-install.sh.

Skriptu koks (to palaišanas secība) izskatās apmēram šādi:

  • master-install
  • koplietošanas funkcijas (koplietojamās funkcijas)
  • informācija (informācijas izvade)
  • modeļi (instalācijas parametru iestatīšana, pamatojoties uz servera modeli)
  • ready_utils (nepieciešamo utilītu uzstādīšana)
  • fwupdate (programmaparatūras atjauninājums)
  • Diag (elementārā diagnostika)
  • biosconf (BIOS/UEFI iestatījumi)
  • pulksteņa fiksētājs (laika iestatīšana mātesplatē)
  • srmconf (attālās saskarnes interfeisa konfigurācija)
  • raidconf (loģisko sējumu konfigurēšana)

viens no:

  • pirmsinstalēšana (vadības pārsūtīšana uz OS vai hipervizora instalētāju, piemēram, ESXi)
  • sapludināta instalēšana (tūlītēja attēla izpakošanas sākums)

Tagad mēs zinām:

  • kā palaist serveri, izmantojot PXE;
  • kā pārsūtīt kontroli uz savu skriptu.


Turpināsim. Aktuāli kļuva šādi jautājumi:

  • Kā identificēt serveri, kuru gatavojam?
  • Kādas utilītas un kā konfigurēt serveri?
  • Kā iegūt iestatījumus konkrētam serverim?

Kā identificēt serveri, kuru gatavojam?

Tas ir vienkārši - DMI:

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

Šeit ir viss nepieciešamais: pārdevējs, modelis, sērijas numurs. Ja neesat pārliecināts, ka šī informācija ir pieejama visos serveros, varat tos identificēt pēc to MAC adreses. Vai arī abos veidos vienlaikus, ja serveru piegādātāji ir atšķirīgi un dažiem modeļiem vienkārši nav informācijas par sērijas numuru.

Pamatojoties uz saņemto informāciju, no instalācijas servera tiek uzstādītas tīkla mapes un tiek ielādēts viss nepieciešamais (utilītas, programmaparatūra utt.).

Kādas utilītas un kā konfigurēt serveri?

Es nodrošināšu utilītas Linux dažiem ražotājiem. Visi komunālie pakalpojumi ir pieejami oficiālajās pārdevēju vietnēs.

“dari pats” Bare-Metal nodrošināšana vai automātiska serveru sagatavošana no nulles

Ar programmaparatūru, manuprāt, viss ir skaidrs. Tie parasti ir iesaiņotu izpildāmo failu veidā. Izpildāmais fails kontrolē programmaparatūras atjaunināšanas procesu un ziņo par atgriešanas kodu.

BIOS un IPMI parasti tiek konfigurēti, izmantojot veidnes. Ja nepieciešams, veidni var rediģēt pirms lejupielādes.

Dažu pārdevēju RAID utilītas var arī konfigurēt, izmantojot veidni. Ja tas tā nav, jums būs jāraksta konfigurācijas skripts.

RAID iestatīšanas procedūra visbiežāk ir šāda:

  • Mēs pieprasām pašreizējo konfigurāciju.
  • Ja jau ir loģiski masīvi, mēs tos izdzēšam.
  • Apskatīsim, kādi fiziskie diski ir un cik to ir.
  • Izveidojiet jaunu loģisko masīvu. Kļūdas gadījumā procesu pārtraucam.

Kā iegūt iestatījumus konkrētam serverim?

Pieņemsim, ka visu serveru iestatījumi tiks saglabāti instalācijas serverī. Šajā gadījumā, lai atbildētu uz mūsu jautājumu, vispirms jāizlemj, kā pārsūtīt iestatījumus uz instalācijas serveri.

Sākumā jūs varat iztikt ar teksta failiem. (Nākotnē, iespējams, vēlēsities izmantot teksta failu kā rezerves metodi iestatījumu pārsūtīšanai.)

Jūs varat “koplietot” teksta failu instalācijas serverī. Un pievienojiet tā stiprinājumu mount.sh skriptam.

Piemēram, rindas izskatīsies šādi:

<sērijas numurs> <resursdatora nosaukums> <apakštīkls>

Šīs rindas inženieris no savas darba mašīnas pārsūtīs uz failu. Un tad, uzstādot serveri, no faila tiks nolasīti parametri konkrētam serverim.

Taču ilgtermiņā labāk ir izmantot datu bāzi, lai saglabātu servera instalāciju iestatījumus, stāvokļus un žurnālus.

Protams, ar datu bāzi vien nepietiek, un būs jāizveido klienta daļa, ar kuras palīdzību iestatījumi tiks pārsūtīti uz datu bāzi. To ir grūtāk ieviest, salīdzinot ar teksta failu, taču patiesībā viss nav tik grūti, kā šķiet. Pilnīgi iespējams uzrakstīt minimālu klienta versiju, kas vienkārši pats pārsūtīs datus uz datu bāzi. Un turpmāk būs iespēja pilnveidot klienta programmu brīvajā režīmā (atskaites, uzlīmju drukāšana, paziņojumu sūtīšana utt., kas ienāk prātā).

Veicot konkrētu pieprasījumu datu bāzei un norādot servera sērijas numuru, saņemsim nepieciešamos parametrus servera konfigurēšanai.

Turklāt mums nebūs jāizdomā slēdzenes vienlaicīgai piekļuvei, kā tas ir teksta faila gadījumā.

Mēs varam ierakstīt konfigurācijas žurnālu datubāzē visos posmos un kontrolēt instalēšanas procesu, izmantojot sagatavošanas posmu notikumus un karogus.

Tagad mēs zinām, kā:

  • sāknēt serveri, izmantojot PXE;
  • pārsūtīt kontroli uz mūsu skriptu;
  • identificēt serveri, kas jāsagatavo pēc tā sērijas numura;
  • konfigurējiet serveri, izmantojot atbilstošās utilītas;
  • pārsūtiet iestatījumus uz instalācijas servera datu bāzi, izmantojot klienta daļu.

Mēs uzzinājām, kā:

  • instalētais serveris saņem nepieciešamos iestatījumus no datu bāzes;
  • visa sagatavošanās gaita tiek fiksēta datubāzē (logi, notikumi, skatuves karogi).

Kā ar dažāda veida programmatūras instalēšanu? Kā instalēt hipervizoru, kopēt virtuālo mašīnu un to visu konfigurēt?

Failu sistēmas attēla (linux) izvietošanas gadījumā aparatūrā viss ir pavisam vienkārši:

  • Pēc visu servera komponentu iestatīšanas mēs izvietojam attēlu.
  • Instalējiet grub sāknēšanas programmu.
  • Mēs chroot un konfigurējam visu nepieciešamo.

Kā pārsūtīt vadību uz OS instalētāju (kā piemēru izmantojot ESXi).

  • Mēs organizējam vadības nodošanu no mūsu skripta uz hipervizora instalētāju, izmantojot automātiskās atbildes failu (kickstart):
  • Mēs izdzēšam pašreizējos diska nodalījumus.
  • Izveidojiet nodalījumu ar izmēru 500 MB.
  • Mēs atzīmējam to kā sāknējamu.
  • Formatēt uz FAT32.
  • Mēs kopējam ESXi instalācijas failus uz sakni.
  • Syslinux instalēšana.
  • Kopējiet syslinux.cfg uz /syslinux/

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

  • Kopējiet mboot.c32 uz /syslinux.
  • Boot.cfg jābūt kernelopt=ks=ftp:// /ks_esxi.cfg
  • Mēs restartējam serveri.

Pēc servera atsāknēšanas ESXi instalēšanas programma tiks lejupielādēta no servera cietā diska. Visi nepieciešamie instalēšanas faili tiks ielādēti atmiņā un pēc tam tiks sākta ESXi instalēšana atbilstoši norādītajam automātiskās atbildes failam.

Šeit ir dažas rindiņas no automātiskās atbildes faila ks_esxi.cfg:

%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

Šajā posmā tiek instalēts un konfigurēts hipervizors, kā arī tiek kopētas virtuālās mašīnas.

Kā tagad konfigurēt virtuālās mašīnas?

Mēs nedaudz krāpāmies: instalēšanas laikā failā VM1.vmx iestatījām parametru guestinfo.esxihost.id = "$SYSSN" un norādījām tajā esošā fiziskā servera sērijas numuru.

Tagad pēc palaišanas virtuālā mašīna (ar instalētu vmware-tools pakotni) var piekļūt šim parametram:

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

Tas ir, VM varēs sevi identificēt (tā zina fiziskā resursdatora sērijas numuru), veikt pieprasījumu instalācijas servera datu bāzei un saņemt parametrus, kas jākonfigurē. Tas viss ir apkopots skriptā, kas ir jāpalaiž automātiski, startējot guestos vm (bet vienreiz: RunOnce).

Tagad mēs zinām, kā:

  • sāknēt serveri, izmantojot PXE;
  • pārsūtīt kontroli uz mūsu skriptu;
  • identificēt serveri, kas jāsagatavo pēc tā sērijas numura;
  • konfigurējiet serveri, izmantojot atbilstošās utilītas;
  • pārsūtīt iestatījumus uz instalācijas servera datu bāzi, izmantojot klienta daļu;
  • konfigurēt dažāda veida programmatūru, tostarp esxi hipervizora izvietošanu un virtuālo mašīnu konfigurēšanu (viss automātiski).

Mēs uzzinājām, kā:

  • instalētais serveris saņem nepieciešamos iestatījumus no datu bāzes;
  • visa sagatavošanās gaita tiek fiksēta datubāzē (logi, notikumi, skatuves karogi).


Apakšējā līnija:

Es uzskatu, ka šī risinājuma unikalitāte slēpjas tā elastībā, vienkāršībā, iespējās un daudzpusībā.

Lūdzu, rakstiet komentāros, ko jūs domājat.

Avots: www.habr.com

Pievieno komentāru