Jak przygotować serwer do kolokacji?

Dlaczego przygotowanie robi różnicę

Widzieliśmy już niemal wszystko. Serwer dostarczony bez skonfigurowanego IPMI — bo "przecież SSH działa". Zasilacz z wtyczką C14 w rack zasilany gniazdami C19. Firmware z datą wydania 2016, z niezałataną luką CVE i ustawionym hasłem BIOS, którego właściciel już nie pamiętał. Wszystkie te sytuacje łączy jedno: można im było zapobiec, poświęcając godzinę przed transportem.

Przeniesienie serwera do datacenter to nie jest event jednorazowy — to pierwsza operacja w długim cyklu życia. To, jak sprzęt trafi do szafy, wpływa bezpośrednio na to, jak szybko można nim zarządzać zdalnie, jak reagować na awarię i czy technik remote hands będzie w stanie cokolwiek zrobić bez Twojej fizycznej obecności.

Ta lista nie jest generyczna. Opiera się na konkretnych problemach, które widzieliśmy przy przyjmowaniu sprzętu. Jeśli masz wątpliwości co do któregokolwiek punktu, skontaktuj się z nami przed dostarczeniem — a nie po tym, jak coś przestanie działać.

Inwentaryzacja sprzętu — co spisać zanim wyjedziesz

Minimalna dokumentacja przed transportem: producent, model, numer seryjny, liczba gniazd zasilania (i typy wtyczek), liczba i typ kart sieciowych, zainstalowana pamięć RAM, konfiguracja dysków. Brzmi trywialnie, ale w praktyce ta informacja często nie istnieje w żadnej ustrukturyzowanej formie.

Pobór mocy: nie przepisuj wartości z etykiety — to moc szczytowa w warunkach pełnego obciążenia. Zmierz rzeczywiste pobory przy typowym obciążeniu roboczym. Narzędzia takie jak ipmitool, Dell OpenManage lub HP iLO dostarczą aktualnych pomiarów. Różnica między "rated 750W" a rzeczywistymi 280W ma bezpośrednie przełożenie na alokację zasilania w szafie.

Osobno spisz uruchomione usługi i porty sieciowe. Jeśli serwer będzie umieszczony za firewalliem DC, ta lista jest niezbędna do stworzenia pierwszych reguł ACL. Brak tej informacji oznacza albo otwarty ruch na wszystkim, albo kilka godzin debugowania po przeprowadzce.

Zasilanie — najczęstszy problem przy przyjęciu sprzętu

Szafy serwerowe w datacenter są zasilane z PDU o określonej amperaturze — najczęściej 16A lub 32A per gałąź. Jeśli Twój serwer ma dwa zasilacze i każdy pobiera 12A szczytowo, a oba trafiają na tę samą gałąź PDU 16A, właśnie stworzyłeś problem. Nie hipotetyczny — realny: bezpiecznik zadziała przy nieskoordynowanym uruchomieniu lub pod pełnym obciążeniem.

Redundancja PSU ma sens tylko wtedy, gdy zasilacze są podłączone do różnych gałęzi PDU (lub, idealnie, różnych torów zasilania A/B). Serwer z dwoma zasilaczami wpiętymi w ten sam listwa to nie redundancja — to iluzja. Upewnij się przed przyjazdem, że rozumiesz topologię zasilania w szafie i masz od nas pisemne potwierdzenie, do jakiego toru trafia każde gniazdko.

Przy jednozasilaczowych serwerach produkcyjnych warto poważnie rozważyć zewnętrzny moduł redundancji zasilania (np. Powerware Hot-Swap lub analogiczne). Przerwa zasilania jednego PSU bez redundancji oznacza po prostu reboot — i to w najgorszym możliwym momencie.

IPMI / BMC — bez tego jesteś ślepy

IPMI (Intelligent Platform Management Interface) lub jego producenckie odpowiedniki — iDRAC (Dell), iLO (HPE), IMM/XCC (Lenovo) — to jedyna droga zarządzania serwerem niezależna od stanu systemu operacyjnego. Bez sprawnego BMC nie możesz zdalnie zrestartować zawieszonego systemu, obejrzeć konsoli systemowej, zamontować obrazu ISO ani sprawdzić, czy serwer w ogóle próbuje się uruchomić.

Przed transportem: przypisz statyczny adres IP do portu zarządzającego (NIE do portu produkcyjnego — BMC powinien mieć dedykowany interfejs lub co najmniej VLAN zarządzający), ustaw silne hasło, włącz dostęp przez SSH lub HTTPS i przetestuj zdalne połączenie. Nie z sieci lokalnej obok serwera — ze zdalnej sieci, przez VPN, tak jak będziesz to robił po kolokacji.

Skonfiguruj również alert mailowy lub SNMP trap przy zdarzeniach krytycznych: awaria zasilacza, przegrzanie, błąd pamięci ECC, awaria dysku. BMC potrafi powiadomić Cię o problemie zanim OS zdąży to zarejestrować — ale tylko jeśli wcześniej to skonfigurujesz.

Konfiguracja sieci przed dostarczeniem

Ustal z nami przed przyjazdem: jakie adresy IP mają być przypisane do interfejsów produkcyjnych, jaka maska, jaki gateway, jakie serwery DNS. Jeśli planujesz VLAN — jego numer i konfigurację po naszej stronie. Jeśli potrzebujesz VPN site-to-site — typ (IPsec/WireGuard), parametry i klucze. Jeśli masz własny blok IP i chcesz rozgłaszać go przez BGP — numery AS i prefiks.

To nie są informacje, które można "dogadać w trakcie". Konfiguracja sieciowa po stronie DC wymaga naszego działania — przypisania portu do VLANu, konfiguracji routera brzegowego, ew. ustawienia sesji BGP. Bez wcześniejszych ustaleń serwer wyląduje w szafie i będzie czekał, aż ktoś to ogarnie.

Jeśli przenosisz serwer, który aktualnie obsługuje ruch produkcyjny, zaplanuj okno migracyjne. Zmiana adresacji IP przy zachowaniu działających usług wymaga koordynacji — szczególnie jeśli masz rekordy DNS z krótkim TTL, certyfikaty TLS przypisane do konkretnego IP lub hardkodowane adresy w konfiguracji aplikacji.

Backup przed transportem

Transport niszczy sprzęt rzadziej niż się wydaje, ale nie na tyle rzadko, żeby ignorować ryzyko. Dyski HDD szczególnie — głowica po wyjeździe z parku jest podatna na uszkodzenia mechaniczne przy wstrząsach. Zrób pełny backup przed wyjazdem i przetestuj go. "Przetestuj" znaczy: spróbuj odtworzyć dane lub maszynę z tej kopii — nie "sprawdź, czy plik istnieje".

Optymalnie: snapshot maszyny wirtualnej (jeśli serwer jest VM), lub obraz dysku (Clonezilla, dd z kompresją) dla fizycznych, przechowywany w innej lokalizacji niż serwer źródłowy. Backup na tym samym serwerze lub szafie nie jest zabezpieczeniem na czas transportu — jest zabezpieczeniem na błąd użytkownika, co też jest wartościowe, ale nie w tym scenariuszu.

Upewnij się, że masz kopię konfiguracji systemu i usług poza dyskiem serwera: pliki konfiguracyjne, skrypty startowe, certyfikaty, klucze SSH. Gitowy repozytorium konfiguracji lub Ansible playbook to najlepsze, co możesz tu zrobić. Odtworzenie systemu od zera z playbooka jest zwykle szybsze niż przywracanie z obrazu dysku.

Remote Hands — co możemy zrobić bez Twojej obecności

Remote Hands to usługa, w której nasz technik wykonuje fizyczne czynności przy Twoim sprzęcie na Twoje zlecenie — bez konieczności Twojego przyjazdu do DC. Zakres jest szeroki: podłączenie kabli, wymiana dysku (który dostarczysz kurierem), reboot przez fizyczny przycisk, odczytanie kodu błędu z wyświetlacza LCD, podłączenie konsoli szeregowej i przeprowadzenie przez nią operacji.

Żeby Remote Hands działał sprawnie, musisz przygotować dokumentację sprzętu: gdzie są porty, który kabel do czego idzie, jak wygląda normalny stan (diody, wyświetlacz). Technik, który widzi serwer pierwszy raz, bez dokumentacji może zrobić mniej niż powinieneś oczekiwać. Z dobrą dokumentacją — znacznie więcej.

Limity: nie robimy operacji software'owych wymagających dostępu do systemu operacyjnego bez wcześniejszego ustalenia procedury. Wymiana hardware bez gwarancji kompatybilności z Twojej strony — też nie. Ale podłączenie konsoli KVM, wgranie BIOS z pendrive, który wyślesz kurierem, albo fizyczne przełączenie kabla sieciowego — to standardowe zlecenia.

Dokumentacja — dla następnego człowieka i dla siebie za rok

Minimum, które powinno istnieć po kolokacji: schemat fizyczny (który serwer, w której szafie, w którym U), schemat logiczny sieci (adresy, VLANy, routing), dane dostępowe do BMC (przechowywane bezpiecznie, nie w Excelu na pulpicie), lista uruchomionych usług i ich konfiguracja.

Dokumentacja techniczna starzeje się szybko, ale nawet nieaktualna jest lepsza niż żadna — pod warunkiem, że jest oznaczona datą ostatniej weryfikacji. Narzędzia takie jak NetBox do dokumentacji sieci i sprzętu, Confluence lub nawet dobrze utrzymany Git repo z plikami Markdown są tu wystarczające. Ważne, żeby dokumentacja była dostępna dla więcej niż jednej osoby.

Pamiętaj też o dokumentacji procedur awaryjnych: co zrobić, gdy serwer nie odpowiada. Kto dzwoni do kogo, w jakiej kolejności, co ma dostęp remote hands wykonać samodzielnie, a co wymaga Twojej autoryzacji. Ta procedura, spisana przed awarią, jest warta wielokrotnie więcej niż ta sama procedura improwizowana o 3 w nocy.