Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Posts Tagged ‘Dell

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

Gdzie jest ta linia ?

Z okazji posiadania pewnej ilości sprzętu pod opieką, miałem ostatnio okazję przeżyć 2 prawie symultaniczne usterki w swoich serwerach. Sam będąc do tej pory przeważnie po drugiej stronie barykady (to mnie wzywano) mogłem sprawdzić jak obecnie wygląda obsługa klienta w standardowym pakiecie gwarancyjnym dla maszyn serwerowych.

Obiekty usterek:

Serwer DELL T300 – problem z kartą DRAC (Dell Remote Access Controller) – brak komunikacji, po restarcie serwera alert o braku tejże karty. Efekt: brak dostępu za pomocą DRAC.

Serwer HP DL380 G5 – uszkodzone 2 redundantne zasilacze (jednocześnie!). Efekt: pomarańczowa dioda na obu i zero możliwości pracy serwera.

Obydwa serwer na standardowej  gwarancji: 3-3-3 (parts-labour-on site)

Sposób zgłoszenia usterki: w obu przypadkach kanał internetowy

Zgłoszenie usterki:

W obu przypadkach wykorzystałem z premedytacją kanał internetowy – nie miałem ochoty przechodzić przez etap infolinii z jej ‚W czym leży problem?”.

W obu firmach należy w pierwszym etapie założyć konto, jeżeli już takowe posiadamy po prostu logujemy się do swoich zasobów.  W przypadku rejestracji mały minus dla Della – po założeniu konta na stronie polskiej parametry logowania nie działały na stronie domyślnej (www.dell.com).

Poszukiwanie strony „managera zgłoszeń serwisowych’” jest tak samo uciążliwe w przypadku obu firm, chociaż również minusik dla Della za precyzyjne ukrywanie jakichkolwiek informacji o kontakcie z supportem technicznym. HP ma to dosyć jasno i sprawnie opisane, łącznie z numerami infolinii, Dell jak wspomniałem wymaga dłuższego grzebania i tłumaczenia fraz z ‚polish’ na ‚english’ aby zrozumieć co autor miał na myśli.

  • Parametry

Parametry niezbędne do zarejestrowania zgłoszenia są w miarę podobne, jednakże w przypadku HP musimy precyzyjnie podawać zarówno model jak i S/N maszyny. Z tego co pamiętam ze swojej strony barykady, odnalezienie PartNumberu(Model/Type) maszyny było zawsze problematyczne – działy IT w najlepszym przypadku posiadały w ewidencji sam numer seryjny maszyny. Co prawda są one zapisane na obudowie samej maszyny, aczkolwiek dla osoby nie zaznajomionej ze schematem, może się  okazać że niezbędna jest ponowna wizyta w często odległej serwerowni i doczytywanie znaczków z obudowy.

Dell ma to rozwiązane precyzyjniej – ServiceTag zawiera w sobie jednocześnie model oraz numer seryjny maszyny, co wiąże z łatwym dostępem do informacji o jej konfiguracji. HP po zmianie S/N z 12 na 10 cyfrowe straciło tą umiejętność wprowadzając dodatkowo Model/Typ. Plusik dla Dell’a.

  • Interfejs zgłoszeniowy

Jednym słowem – Dellowy to porażka. Tragicznie wykonany, wolny i zawodny, spowodował iż jedno zgłoszenie musiałem wypełniać 4 razy. Za każdym razem po naciśnięciu „Wyślij„, po długim okresie oczekiwania pojawiał się ten sam komunikat o błędzie w przetwarzaniu zgłoszenia, „spróbuj ponownie za jakiś czas”. Spróbowałem. Efektem było, jak mi później wytłumaczył człowiek z Obsługi Klienta, założenie tylu zgłoszeń ile razy próbowałem wykonać to cholerne ‚Wyślij‚. Ten interfejs i sam mechanizm mogę polecać jedynie wyjątkowym masochistom.

W HP wszystko przebiegło bez problemów.

Obydwie firmy dostają minusik za metody odszukiwania wykonanych zleceń, w HP prawie tragiczne jest to iż trzeba posiadać cały numer RMA zlecenia aby go odnaleźć. Po dłuższym grzebaniu doszedłem w obu interfejsach do punktu gdzie z podstawowymi poleceniami nie miałem już problemów.

  • Pierwszy kontakt

Zdecydowanie Dell – oddzwonił w przeciągu 3 godzin od założenia zlecenia (zlecenie zakładane w okolicach południa). W HP pierwsza reakcja nastąpiła dopiero na drugi dzień.

Kontakt z Dellem nastapił z jawnego numeru telefonicznego człowieka z Obsługi Klienta, HP dzwoniło z tradycyjnie ukrytego profilu, tradycyjnie dla infolinii nazwisko osoby dzwoniącej wyartykułowane na przydechu, tak aby klient przypadkiem nie zapamiętał. Plusik dla Dell’a – mniej bezosobowy kontakt rodzi powoduje nieco lepszą obsługę samego zgłoszenia. Co ciekawe – w Dellu przez cały ciąg procesowy kontaktowała się ze mną JEDNA OKREŚLONA osoba, w HP było to co najmniej 2.

Diagnostyka

DELL

Ponieważ awarie nie są ze sobą równoważne,w  żaden sposób nie można porównywać przypadków na zasadzie: ‚a tutaj więcej pytań więc lepiej’. Przypadek Della i jego karty DRAC był jednak dosyć szczególny.

Po nawiązaniu pierwszego kontaktu, już drogą mailową (ze spersonifikowanego konta doradcy, z imieniem i nazwiskiem)  dostałem dalsze instrukcje postępowania: nieśmiertelny raport DSAT (narzędzie do ściagnięcia i wygenerowania raportu dołączone w postaci linku do strony Della), reset karty, próba aktualizacji BIOS, firmware karty, backboard controllera – tak nam zeszło kolejne 24 godziny. Wszystkie operacje odbywały się albo za pomocą mojego zdalnego dostępu, albo bezpośredniego działania na maszynie fizycznej (ustawianie parametrów karty DRAC możliwe jest tylko po POST maszyny) – swoją droga szkoda że Dell nie posiada takowego narzędzia z poziomu OS, tylko nawet uruchamianie softu lokalnie jest odwoływaniem się do niej via IP.

Po wysłaniu kolejnej porcji wyników testów i spostrzeżeń (wciąż na konto określonego doradcy) otrzymałem tą sama drogą kolejne polecenie – reset NVRAMU serwera oraz NVRAMU karty DRAC (obydwa oddzielne). Tu już byłem leciutko zaniepokojony, zwłaszcza iż drobiazgowy kawałek instrukcji wysłany przez doradcę zakładał fizyczna ingerencję w samą maszynę. Starałem się postawić w sytuacji klasycznego admina – reset NVRAMU na produkcyjnym serwerze mógł mieć nieprzewidziane skutki, a już zupełnie katastrofalne w przypadku niespodziewanego wyczyszczenia danych kontrolera PERC o założonych RAIDach.  Podchwytliwe pytanie do doradcy (swoją droga – nie podejrzewałem Della o takie praktyki, ale niech się facet orientuje) i zapewnienie z jego strony że czyszczenie NVRAMU nie usuwa informacji z kontrolera PERC.

Okej, bawimy się dalej. Zabawa w przestawianie zworki, 20 sekund, powrót, wejście do konsoli DRAC, reset do ustawień domyślnych.

Nic … dalej to samo …

Ostatnia wskazówka ze strony Dell – proszę sprawdzić czy podpięcie bezpośrednio do złącza DRAC z laptopem coś da. Ano dało – czystą i stabilną konekcję. Cóż nam jednak po tym skoro dalej w sieci interfejsu nie widać?

Ostatecznie problem zakończył się zmianą IP’ka karty na nieco inny niż chcieliśmy, aczkolwiek we wskazanej przez nas podsieci DRAC działać nie chciał. Żadne z nas nie wie dlaczego – ani DHPC, ani static nie rozwiązywały problemów. Na tym etapie postanowiłem zgłoszenie w Dellu zamknąć – dostałem podziękowanie za uwagę i voila … koniec.

Wniosek z sytuacji był następujący: fajnie że ktoś wdraża system utartej ścieżki, bardzo rzadko zdarzają się nieoczywiste sytuacje, które jeszcze nie istnieją w bazie rozwiązań. Świetnie że ktoś stara się rozwiązać problem myślowo, zanim wyśle ekipę silnorękich, której utrzymanie i wyjazd  przecież kosztują 😉 Super …. aczkolwiek ten mały posmak ‚weź se pan rozkręć serwer i se pan zresetuj’ pozostaje 😦

Czy jestem niezadowolony? Nie, absolutnie nie. Personalizacja doradcy, ludzki kontakt, nie wymądrzanie się wiedzą tajemną – to były atuty które spowodowały że bez większego zamieszania sprawa szła do przodu. Jednak, patrząc na to z perspektywy admina, na widoczne problemy w logach (znikająca karta) i wymogów technicznych jakie stawiano Zgłaszającemu rodzi się pytanie ‚ Czy nasi bracia w rozumie, po drugiej stronie Oceanu również są tak szczegółowo czołgani, czy też wystarczy krótki telefon na ServiceLine i oświadczenie ‚Ja się nie dotykam, przyjeźdżajcie ;)’?

HP

Dziwne uszkodzenie –  2 zasilacze na raz. UPS do którego były podłączone nie zanotował żadnych wydarzeń związanych z brakiem czy nadmiarem zasilania – ot …. wzięło się i popsuło.

Jak mówiłem HP zareagowało mniej więcej po 12 godzinach od zgłoszenia (w porównaniu z 3 od Della) – już 12h maszyna produkcyjna (serwer plików w średniej firmie) nie działa. Anonimowy telefon (unknown), równie anonimowy doradca przedstawiający się na przydechu i pytanie „Co się stało…”. Korciło mnie aby w amerykańskim stylu odpowiedzieć ‚Coś mi nie działa …”. Na spokojnie jednak podałem problem, oczywiście usłyszałem nieśmiertelne pytania o kolory diodek (amber), czy jestem pewny że w okolicy nie wywaliło jeszcze co najmniej 20 bezpieczników i 70 UPS’ów, oraz czy aby NA PEWNO jest podpięty UPS i czy mógłbym go ominąć i podpiąć kable zasilające bezpośrednio do sieci.

No mógłbym, chociaż efekt znałem od razu. ‚Okej, to my oddzwonimy…’. Super. Czekam.

Za godzinę zadzwonił już inny kolega pytając czy wiem co to jest program CRU (Customer Replaceable Unit) i czy potwierdzam adres wysyłki. Jasne, wiem, program oszczędzania kasy po stronie HP – zamiast wysyłać serwisanta wysyła się same części licząc że proste wymiany – hot plugowy zasilacz czy dysk da radę wymienić nawet Główny Księgowy 😉 Okej, potwierdziłem adres, dostałem kolejne pytanie czy ROZUMIEM że uszkodzone części mam odesłać na koszt HP do magazynu serwisowego i czy aby na pewno to zrobię, po czym padło nieśmiertelne ‚To ja wystawiam zlecenie do logistyki’.

Dlaczego nieśmiertelne? Ano dlatego zgłoszeń elementów CRU to ja wykonałem dziesiątki i na palcach jednej ręki pijanego drwala mogę policzyć przypadki kiedy części był już na DRUGI dzień. Zazwyczaj tejże logistyce zajmowało to coś koło 36 h najbidniej.

Tu jednak zostałem mile zaskoczony – na drugi dzień koło g. 14 zjawił się kurier z paczuszką od EjczPi, która o dziwo zawierała dwa zasilacze do DL380G5. O dziwo (x2) zadziałały 😉

Wysyłka zwrotna uszkodzonych części poszła dnia następnego, co zupełnie nie przeszkodziło w dzień kolejny zadzwonić do mnie trzeciej z kolei osobie pytając czy NA PEWNO odesłałem części. Odesłałem. Słowo.

Przypadek prosty, niemal banalny – z wyjątkiem zaskoczenia ‚dlaczego dwa na raz?’ W którym z dialogów udało mi się wydusić od doradcy iż problem jest znany i opublikowany w którymś z ‚Service Advisory’. Fajnie, tylko od czasu jak EjczPi w trybie natychmiastowym wywaliło z OARS’a wszystkie ciekawsze dane serwisowe, pozostawiając prosty chłam na bazie zdjątek i parametrów, jakiekolwiek poszukiwania czegoś innego niż CaseStudy i WhitePapers stało się koszmarem.

Tyle z zabawy z serwerami 😉

Edit: O dziwo, Dilbert się ze mną zgadza – akurat zamieszczając bardzo dobry komentarz 😉

Written by marcinbojko

Maj 3, 2010 at 19:04

Napisane w Uncategorized

Tagged with , , ,

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 blogerów lubi to: