DRBL – z czym się to je, część II – instalacje OS | Blog

DRBL – z czym się to je, część II – instalacje OS | Blog

DRBL – z czym się to je, część II – instalacje OS | Blog Marcina Bojko
1z3
http://marcinbojko.wordpress.com/2009/06/20/drbl-z-czym-sie-to-je-c...
Blog Marcina Bojko
Linux,Windows,serwer, i tak dalej ;)
DRBL – z czym się to je, część II – instalacje OS
Jak działa to w praktyce ? Otóż bardzo fajnie. System jest wyposażony w odpowiedni skrypt który sam
pobierze i zainstaluje mini-instalacje powyżej zebranych dystrybucji. Oznacza to – iż chcemy np. mieć
możliwość instalacji Debiana (Etch i Lenny) zarówno w wersji 32 jak i 64 bitowej, uruchamiamy
odpowiedni skrypt (net-install) z parametrem Debian i za chwilę możemy cieszyć się dodatkowymi
opcjami dodanymi do menu PXE.
Dalsza część usprawniania instalacji to oczywiście parametry przekazywane do instalatora w trakcie
jego uruchomienia. Możemy wybrać jedno z właściwych repozytoriów Debiana, przekazać parametry
instalacji …. lub możemy skorzystać z w pełni zautomatyzowanych systemów instalujących (FAI dla
Debiana, AutoYAST dla SuSE)
W czasie pracy najwięcej czasu poświęciłem projektowi AUTOYAST, który dostępny jest dla systemów
SuSE (openSuSE, Novellowe SLED i SLES). Ten w pełni dojrzały projekt pozwala nam na totalną i
pełną konfigurację instalowanego systemu przez zestaw dyrektyw i parametrów zapisywanych w
składni XML. Mamy wpływ na każdy etap procesu instalacji – zaczynając od parametryzacji dysków,
partycji, filesystemów, rozmiarów instalacji, wybranych pakietów, startujących usług, konfiguracji
wszelakich usług, uruchamiania dodatkowych skryptów (zarówno w fazie PRE jak i POST
instalacyjnej), na integracji z LDAP i wykorzystaniu informacji z tegoż systemu do parametryzacji
wszelakich instalacji.
Ba, dzięki podziałowi na fazy PRE i POST możliwe są takie rzeczy jak przygotowywanie własnych
modułów do obsługi sprzetu (np. nietypowych lub nieobsługiwanych standardowo kart sieciowych,
dostarczenie ich w fazie PRE a następnie kontynuacja instalacji w fazie POST)
System posiada własny edytor, dla zaawansowanych zostaje wersja XML do edycji ręcznej. Narzędzie
jest bardzo wygodnie – wynikiem procesu projektowania jest plik XML którego lokalizację
przekazujemy za pomocą PXE i DRBL’a do instalatora. Przygotować możemy nieskończoną ilość
takich profilowanych instalacji dołączając je kolejno do menu instalatora.
Przykładowa dyrektywa instalacji stosowanych przeze mnie:
2013-10-09 23:12
DRBL – z czym się to je, część II – instalacje OS | Blog Marcina Bojko
2z3
http://marcinbojko.wordpress.com/2009/06/20/drbl-z-czym-sie-to-je-c...
label Instalacja
# MENU DEFAULT
# MENU HIDE
MENU LABEL Instalacja zaplecze v.2.xx
# MENU PASSWD
TEXT HELP
* Instalacja systemu operacyjnego SLED 10 SP1
ENDTEXT
kernel linux
append initrd=initrd.200902 ramdisk_size=128000 splash=silent showopts
install=hOp://172.16.0.1:/sled server=172.16.0.1 serverdir=/sled autoyast=hOp://172.16.0.1
/sled/autoyast-net-raid.xml language=pl_PL
Jak wygląda wydajność takiego rozwiązania? Systemy sprofilowane (SLED 10 SP1) na maszynach klasy
Intel Celeron (1.8/2.0) z 1 GB RAM, z pełnym oprogramowaniem projektowym instalują się około 45
minut. Niesamowitym plusem takiego rozwiązania, przy zastosowaniu szybszych interfejsow
Gigabitowych jest fakt, iż jednocześnie może trwać instalacja wielu maszyn. W testach
przeprowadzanych przez nas do 5 maszyn jednocześnie spowolnienie instalacji było niewidoczne (sieć
lokalna, interfejsy i switche gigabitowe).
Przy wzroście ilości maszyn do 10 na raz czas instalacji per wzrósł o ok.5 do 7 minut. Oznacza to, iż
średniej klasy maszyna (desktop jako serwer) jest w stanie przeprowadzić około 80 instalacji dziennie
w 8 godzinnym cyklu pracy. Zakładając możliwość dostawienie drugiego interfejsu – liczba wzrasta do
150 w cyklu 8 godzinnym.
Warto zaznaczyć iż instalacja jest totalnie bezobsługowa – można nawet nie wykorzystywać
monitorów do obserwacji procesu. Prostym wpisem w autoyast całość instalacji kończymy
shutdownem – oznacza to iż każda z maszyn które własnie go wykonały są gotowe do spakowania do
pudełka lub wykorzystania w projekcie.
Rozwinięciem idei instalacji bezdotykowej jest zastosowanie sieci serwerów DRBL jak na poniższej
ilustracji:
2013-10-09 23:12
DRBL – z czym się to je, część II – instalacje OS | Blog Marcina Bojko
3z3
http://marcinbojko.wordpress.com/2009/06/20/drbl-z-czym-sie-to-je-c...
Poszczególne serwery rozproszone w innych lokalizacjach (inny budynek, inne miasto, inny kraj)
pozwalają na wykonywanie dokladnie tych samych czynności w oddziałach, używając tych samych
(lub odpowiednio zmodyfikowanych korzystając z LDAP/AD) parametrów.
Za całość procesu synchronizacji odpowiadać może subsystem RSYNC skonfigurowany tak aby
weryfikować i naprawiać ewentualne błędy za pomocą weryfikacji sum kontrolnych MD5.
Najciekawiej wygląda zarządzanie zmianą w tego typu projekcie – z racji niewielkich rozmiarów
zarówno samego autoyast.xml , jak i poszczególnych pakietów wchodzących w sklad instalacji,
aktualizację założeń instalacji, aktualizację pakietów instalacyjnych można przeprowadzić dosłownie w
kilka minut.
W praktyce przesłanie samych założeń instalacji trwa około 2 minut w przypadku 6 dodatkowych
rozproszonych lokalizacji. Gdy w grę wchodzą pakiety dodatkowe wykorzystujemy przetwarzanie
równoległe – wiele jednoczesnych procesów synchronizacji (wykorzystujących fakt iż łacze serwera
centralnego jest wielokrotnie bardziej wydajne niż łącza poszczególnych serwerów oddziałowych.
Ponieważ jednocześnie, oprócz samych opisow instalacji przesyłać można obraz wykonane za pomocą
systemu Clonezilla sam DRBL okazał się doskonałym uzupełnieniem codziennej pracy systemowoprojektowej.
Wyobraśmy sobie projekt w którym z częstotliwością np. miesięczną zmieniają się obrazy instalacyjne
stacji roboczych i nośników. Dystrybucja tychże na nośnikach DVD/USB okazywała się koszmarem –
zawsze zdarzało się iż wersja jak została zainstalowana różni sie od wersji obowiązujacej. Dokładając
do tego czas rozproszenie i przygotowania nośników okazało się to sporym problemem.
Rozwiązanie przyszło w postacji maszyny DRBL – zawsze dostępnej z tym samym menu co ostatnio.
Zawartość obrazów mogła zostać zaktualizowana, instalator mógł wykonywać zupełnie nowe
czynności, jednakże z punktu widzenia instalującego NIC się nie zmieniało. Zawsze witał go ten sam,
widziany ostatnio obrazek
WriOen by marcinbojko
Czerwiec 20, 2009 @ 12:21
Napisane w Uncategorized
Tagi: debian, drbl, etch, filesystem, internet, linux, open source, opensuse, work
Blog na WordPress.com. The Journalist v1.9 Theme. Autor motywu: Lucian E. Marin.
2013-10-09 23:12