Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Posts Tagged ‘IBM

DRBL – mechanizm klonowania.

Wspominałem wcześniej o jednej z podstawowych funkcjonalności serwerów DRBL – mechaniźmie klonowania stacji roboczych z wykorzystaniem wspólnej pracy Clonezilli i PXE. W skrócie – serwer DRBL zapewnia nam możliwość startu źródłowej stacji roboczej za pomocą PXE, Clonezilla wraz z pakietami towarzyszącymi klonuje zawartość dysków stacji roboczych do plików. Pliki mogą być zapisywane (używając kilku wskazanych metod kompresji) za pomocą SMB/FTP/SSH/NFS lub na lokalnych dyskach. Wspierane filesystemy to min:

  • ext2,
  • ext3,
  • reiserfs,
  • xfs,
  • Jfs
  • FAT16/32,
  • NTFS 3 i 5(streams),
  • HFS+
  • Praca blokowa (block-by-block, sector-by-sector)

Idea ta pozwala na wykonanie jednoczesnych operacji na dowolnej ilości stacji roboczych – co więcej, w zależności od ilości danych i szybkości sieci, samo odtwarzanie/zapisywanie trwa od kilkunastu sekund, do kilkunastu minut.
Wyobrażcie sobie następujące zastosowanie: organizacja, w której wystepuje kilka modeli stacji roboczych. Każda z nich może spełniać inną rolę – od stacji użytkownika wprowadzającego dane po stacje księgujące, graficzne, administracyjne, techniczne – wszystko zależy od zastosowanego profilu oprogramowania lub ustawień systemowych.
Przy każdej awarii lub standaryzacji czeka nas nie lada wyzwanie:

– instalacja OS (często aktywacja ponowna – a więc wyjaśnianie dlaczego właściwie aktywuje się ta kopię po raz kolejny)
– instalacja wszystkich możliwych poprawek, service packów, Support Packów danego producenta itp.
– instalacja niezbędnego oprogramowania
– konfiguracja pod użytkownika

Każdy pracownik działu IT doskonale zna ten schemat. Aby ułatwić sobie życie: wykorzystując DRBL, na jednej ze wskazanych maszyn tworzymy instalację wzorcową (np. OS+poprawki+w miarę stałe ustawienia), resztę doinstalowując za pomocą skryptu z wykorzystaniem wolumenów sieciowych.

Z małą ilością użytkowników (stacje profilowane pod konkretnych userów a nie role) możemy pójśc o krok dalej – przygotowujemy pełny obraz: OS+poprawki+aplikacje+ustawienia charakterystyczne. Czas kompresji i rozmiar pliku wynikowego zależą ściśle od ilościu materiału do kompresji oraz maszyny na jakiej to wykonujemy.

Na szczęście sama dekompresja jest błyskawiczna – mam przygotowane obrazy pod różnych klientów w różnych instytucjach – przeciętny czas odtworzenia stacji roboczej po awarii to około 6 minut (obraz), 2-3 minuty na restart maszyny i dalsza konfiguracja za pomocą skryptu sieciowego – kolejne 3 minuty.

Idąc dalej tym sposobem – o ile jest taka potrzeba, za pomocą mechanizmu WoL możemy zaplanować wykonywanie kopii wskazanych maszyn np. co weekend.

Jak widać w czasie poniżej 15 minut można mieć pełne Disaster Recovery 😉

Co z serwerami zapytacie?
Rewelacyjnie. Wiemy bowiem, iż bez pełnego DR, w środowiskach które nie pracują jako HA – przeważnie posiadając jedną/dwie nie zwirtualizowane maszyny spełniające swoją rolę – metoda ta sprawdza się bardzo dobrze.
Zarówno w środowisku serwerów HP/DELL/IBM oraz innych firm trzecich, przy znikomym nakładzie środków i pracy możemy spokojnie wykonywać kopie OS umieszczane na dyskach macierzowych (SmartArray w HP, ServeRaid w IBM i PERC-H w Dell’u).
Minimalistyczny DR w tego typu maszynach obejmuje:
– konfigurację RAID HW
– odtworzenie OS za pomocą DRBL
– odtworzenie danych dla aplikacji/systemu z backupu.

Dla przykładu: DR zaprojektowany przeze mnie dla 200 maszyn HP DL 380 G4/G5, z Windows 2003, trzema różnymi wolumenami logicznymi (recovery OS), zajmujący około 20GB, odtwarzał się w około 8-9 minut (sieć 1Gb). Synchronizacja partycji z danymi – kolejne 10 minut.

Written by marcinbojko

Czerwiec 21, 2010 at 07:30

Serwery – co potrzebujemy…

Wpis wyewoluował bezpośrednio z wątku o serwerach:  http://www.goldenline.pl/forum/serwery-hardware/1230952. Co powinien posiadać admin opiekujący się serwerami (zakładam serwery a nie PCciki przerobione na serwery) HP/Dell/IBM/Fujitsu-Siemens?

Zawsze warto wykupić możliwie redundantne rozwiązania. W przypadku serwerów innych niż blade, będą to na pewno: zasilacze (zazwyczaj dwa), dyski, być może RAID on RAM, oraz onboardowe karty sieciowe (teaming). To pozwoli nam na kontynuowanie pracy maszyny nawet w przypadku wydawałoby się awarii krytycznej – jak zasilacz, dysk czy kość pamięci.

Zawsze powtarzałem swoim ‚studentom’ – jeżeli wiecie jak naprawić (wyłączając) sprzęt i jak ‚załatać’ do najbliższego okna serwisowego – wybierzcie to drugie rozwiązanie 🙂

ZAWSZE, zwłaszcza w przypadku wielu takich samych serwerów warto posiadać:

  • minimum jeden dysk każdego rozmiaru/interfejsu jaki używamy, lub jeden NAJWIĘKSZY uzywany przez nas. Dla przykładu: mamy dyski 36GB ,72GB ,144 GB SAS. Kupujemy jeden 144 SAS, który obsłuży nam awarię wszystkich pozostałych – do czasu gdy przybędzie nowy model (gwarancja) lub go zakupimy. Ważne: dyski tej samej pojemności muszą posiadać identyczny P/N lub kompatybilne FRU. Z tym zazwyczaj w markowych maszynach problemu nie ma, zdarza się jednak że dostaniemy innym kanałem dysk o identycznej pojemności który jednak ‚nie zaskoczy’. A nie zaskoczy dlatego iż 1 GB nie jest w każdej firmie równy tej samej pojemności. Drobne różnice w ilości sektorów/cylindrów/talerzy lub samo logiczne ich przestawienie spowoduje iż dysk o deklarowanej pojemności po prostu w macierzy ‚nie zaskoczy’. Stąd kolejna uwaga: kupując dysk do macierzy, którego PN nie zgadza się z deklarowanym przez producenta tejże kupmy kolejny dysk z serii pojemności (zamiast 36GB kupmy 72GB)
  • minimum jeden, wskazana para zasilaczy sieciowych (power supply) dla posiadanego modelu. Dlaczego parę a nie jeden? Zasilacze też ludzie, jak głosi przysłowie i lubią siadać parami. Coś takiego wydarzyło mi się dwa razy w życiu, w dwóch różnych modelach serwerów. Rozumiem że można zapewne to wytłumaczyć wadą fabryczną, ale nowe zasilacze przybyły dopiero po 48h 🙂
  • czasem, nadmiarowo jeden lub 2 fany (wentylatory) systemowe – łatwe do odnalezienia i zakupienia
  • zawsze warto posiadać nadmiarowe taśmy/kable, łatwo jest uszkodzić sobie np. taśmę do backplane’ów
  • warto posiadać jeden napęd DVD (combo) więcej – to już raczej opcja dodatkowa.
  • kartę sieciową PCI 32 oparta o jeden z popularnych chipsetów – np. Realtek-8139/3Com-905
  • last but not least – stacja 1.44 na USB. Wiem, wiem, artefakt, ale kilka razy się przydała 🙂

Odpowiadając na pytania na forum – co najczęściej ulega awarii?

W kolejności od najczęściej występujących:

  • dyski magnetyczne,
  • dyski optyczne,
  • dyski magnetooptyczne,
  • zasilacze,
  • kontrolery RAID (onboard/standalone)
  • płyty rozszerzeń (riser board/daughterboard)

Nie ma maszyn odpornych na awarie.

PS. Z newsów – w zapasach posiadam własna matę antystatyczną (uziemianą) oraz opaskę antystatyczną podłączaną do niej. Przyznam się iż jeden z ‚kolegów’ w nowej pracy zaskoczył mnie negatywnie, zwijając się prawie ze śmiechu widząc jak z opaską w ręku zabieram do zbadania bebechów serwera. Na nic tłumaczenia o ‚najlepszych praktykach’ na nic wykład o ESD – argumenty: takowy ‚negatyw’ posiada PC-ta, zawsze naprawiał go z jedną nogą w powietrzu i nigdy nic się nie wydarzyło.

Pozostało mi zapytać: ‚Jakiż to powód tak częstego naprawiania PC?’ 😉

O tempora, o mores 😉

Written by marcinbojko

Październik 22, 2009 at 20:32

Napisane w Uncategorized

Tagged with , , , , ,

%d bloggers like this: