Prawie jak :) czyli jak nie oszaleć z FreeBSD mając jedynie 200 serwerów pod opieką... (c) 2006, Stefan Jurczyk, home.pl
Tylko 1 ekran chwalenia się :) > 200 serwerów, > 350 procesorów, > 600 GB RAM, > 120 TB dysków, 12 km skrętki UTP, 5 łączy GEth, 700 mbit/s ruchu, 30 tysięcy serwerów wirtualnych, 180 tysięcy obsługiwanych domen. > 50 aktywnych urządzeń sieciowych, 120 KVA pobieranej energii elektrycznej,
całość tworzy i zarządza tylko 5 osób w trybie 24h/7d z odległości 525 km...
Zdalny dostęp do konsoli przekierowanie konsoli tekstowej na port szeregowy (RS232): przekierowanie BIOS u, przekierowanie loadera i kernela FreeBSD, obsługa logowania na konsoli, realizacja poprzez: użycie drugiego serwera FreeBSD (minicom), serwery terminali (ssh, do 48 portów), karty zarządzające z IPMI, alternatywa: KVM over IP (obsługa grafiki).
Konfiguracja przekierowania przekierowanie loadera w pliku /boot/loader.conf: console= comconsole comconsole_speed= 115200 machdep.conspeed= 115200 włączenie przekierowania BIOS u na port szeregowy COM1 z szybkością 115200, w niektórych przypadkach zamiana portu COM1 i COM2 w BIOS ie serwera (ustawienia port oraz irq na zmianę).
Tryb wielo-konsolowy wyświetla komunikaty kernela na porcie szeregowym i karcie VGA, obsługa przez dopisanie do pliku /boot/loader.conf: console= comconsole,vidconsole /etc/rc* oraz single mode może wskazywać tylko na 1 port (pierwszy podany w console=), można skonfigurować obsługę logowania się użytkownika tu i tu, modyfikując /etc/ttys: ttyv0 /usr/libexec/getty Pc cons25 on secure ttyd0 /usr/libexec/getty Pc std.115200 vt100 on secure #console /usr/libexec/getty Pc vt100 on secure
Menu loadera własna implementacja menu loadera pokazującego się przy starcie systemu, napisana w forth u, obsługuje tryb wielo-konsolowy, umożliwia wybór konsoli podstawowej (RS232 czy VGA), udostępnia start w single mode, rozbudowanym safe/debug mode oraz start sysinstall a, będzie udostępniona przez autora (http://steve.home.pl).
Zdalne sterowanie zasilaniem problem: zdalne zresetowanie serwera, który przestał odpowiadać, realizacja: dedykowane panele zasilające z zarządzaniem poprzez telnet/ssh/snmp, karty zarządzające zgodne z IPMI, listwy zasilające często umożliwiają monitoring poboru prądu przez serwery, często na nieodpowiadającym serwerze można wejść do kernel debuggera (break sequence) i tam wydać polecenie where/panic/reset.
Dlaczego nie IPMI? IPMI (Intelligent Platform Management Interface) - interfejs pozwalający lokalne jak i zdalne zarządzanie serwerami, realizacja: lokalna implementacja na płytach głównych serwerów, zdalna w postaci karty PCI, problemy: niekompatybilność dostępnych aplikacji między vendorami, aplikacje Windows-only, częsty brak obsługi przekierowania na konsole, problemy z routingiem pakietów IPMI, niekompatybilność z driverami kart sieciowych.
Startowanie FreeBSD poprzez sieć problemy: zdalne instalowanie FreeBSD na serwerach, zdalne ratowanie nie bootujących serwerów, rozwiązanie przez wystartowanie FreeBSD z sieci (bez użycia lokalnych dysków/cd/dvd), PXE (Preboot Execution Environment) - standard umożliwiający załadowanie loadera systemu operacyjnego (dla Free: pxeboot) przez BIOS serwera/karty sieciowej z sieci IP, PXE obsługuje protokoły: IP, DHCP oraz TFTP.
Konfiguracja PXE na serwerze DHCP, w pliku dhcpd.conf: subnet a.b.c.d netmask A.B.C.D {... # Normalna konfiguracja sieci next-server a.b.c.d; # Adres serwera tftp filename "pxeboot"; } włączenie serwera tftp (plik /etc/inetd.conf): tftp dgram wait root /usr/libexec/tftpd tftpd -ls /katalog z plikami startowymi/
Dystrybucja startowa w katalogu wskazanym w konfiguracji tftpd należy umieścić: /pxeboot (dostępny w katalogu /boot), kopię katalogu /boot z kernelem i plikami konfiguracyjnymi (jako podkatalog), plik /mfsroot(.gz) z obrazem systemu, plik /boot/loader.conf zawierający: mfsroot_load="yes" mfsroot_type="mfs_root" mfsroot_name="/mfsroot" vfs.root.mountfrom="ufs:/dev/md0a"
Własny obraz systemu (/mfsroot) standardowy /mfsroot.gz (zgrany z dyskietek startowych) jest mocno ograniczony (sysinstall), można stworzyć własny obraz, zawierający większą ilość utili (fdisk, gjournal, mc, rsync, wget, utile do macierzy dyskowych): dd bs=1024 count=65536 if=/dev/zero of=mfsroot mdconfig -a -t vnode -f mfsroot newfs -O1 /dev/md0; mount /dev/md0 katalog # cp -R /bin /lib /libexec /sbin /rescue katalog # stworzenie mini /etc, dogranie utili i bibliotek umount katalog mdconfig -d -u md0 gzip mfsroot
HomeBSD :) - własna dystrybucja problem: instalowanie/konfigurowanie tych samych elementów na wszystkich serwerach, rozwiązanie: własna dystrybucja FreeBSD, zawierająca już wszystko co używamy, dystrybucja dostępna jako plik *.tgz (do jednokrotnego zainstalowania) lub rozpakowane drzewo dostępne via rsync (aktualizacja), możliwość pełnej personalizacji, wycięcia co nie potrzeba i dodania tego co się używa, z racji ilości zmian w przypadku home.pl jest to rozwinięte do całkowicie własnego distro ze zmianami utrzymywanymi w cvs (HomeBSD).
Problem logo dystrybucji Każda dystrybucja BSD ma swoje logo :)
Nasza także :)
Automatyczny upgrade własna dystrybucja dostępna poprzez rsync to także możliwość automatycznych upgrade ów serwerów podczas ich procedury startu, realizacja - plik /etc/rc.d/sync: #!/bin/sh # PROVIDE: sync # REQUIRE: NETWORKING # BEFORE: devd # KEYWORD: nojail rsync -axvzoh --exclude-from=/etc/rc.ext konto@serwer::katalog /
Historia upgrade ów w home.pl 200 150 100 1997 FreeBSD 2.1 1999 FreeBSD 3.1 2000 FreeBSD 4.0 50 0 2005 FreeBSD 5.4 2006 FreeBSD 6.1
Zabezpieczenia: flagi plików jednym z charakterystycznych elementów systemu UFS/UFS2 są flagi plików, dostępne są flagi blokujące modyfikacje plików (noschg) lub ograniczające je jedynie do dopisywania (dla plików logów - sappend), można zablokować możliwość modyfikacji plików systemowych na serwerach dopisując do /etc/rc.d/sync następujące linie: chflags -R noschg,nosappend /bin /boot /etc /lib /libexec /sbin /usr /var # rsync - jak poprzednio chflags -R schg /bin /boot /etc /lib /libexec /sbin /usr chflags -R sappend /var/log/messages
Zabezpieczenia: secure level flagi plików zabezpieczają przed modyfikacją, jednak można je w dowolnej chwili zdjąć, aby temu zapobiec należy w ramach procedury startu systemu podnieść tzw. secure level (poziom bezpieczeństwa) do 1 (lub więcej :), realizacja - plik /etc/rc.conf: kern_securelevel="1 kern_securelevel_enable="yes" UWAGA: po zastosowaniu tych mechanizmów jedyna metoda zmiany plików to restart i wejście do single mode lub zmiana obrazu dystrybucji i synchronizacja poprzez /etc/rc.d/sync (rsync).
Zabezpieczenia: chroot/jail wszystkie usługi Klienckie (DNS, HTTP, SMTP, POP3, FTP, MySQL, PgSQL, etc) uruchamiane są wewnątrz chroot ów lub jail i, jail to bardziej rozwinięta i bezpieczniejsza wersja chroot a, pozwalająca na uruchomienie określonych procesów i usług w formie zaawansowanego sandboxa, w home.pl jest to rozwinięte do wielopoziomowej formy: poziom launcher a wszystkich usług, poziom serwerów usług (serwer www i ftp jest ograniczony do drzewa z www, smtp i pop3 do drzewa z pocztą), aplikacje Klientów (php, perl, cgi) uruchamiane są w jailu ograniczonym tylko do katalogu WWW Klienta.
Wirtualny FS w jail ach podstawowym problemem z użytkowaniem chroot ów na dużą skalę jest konieczność zapewnienia w każdym chroot cie dostępu do określonych plików systemowych (/etc, /usr/share), bibliotek (/lib, /libexec, /usr/lib) a czasami i plików wykonalnych (/bin, /sbin, /usr), rozwiązaliśmy to modyfikując VFS FreeBSD, tak aby w każdym chroot cie lub jail u wirtualnie dostępna była zawartość ograniczonej wersji katalogów systemowych (/bin, /etc, /usr, itd.), które fizycznie leżą tylko w jednym miejscu (nie kopiujemy ich do każdego jaila), może kiedyś uda nam się przekonać Pawła Dawidka :) do przepisania tego patcha do formy ogólnej jako rozszerzenie mechanizmu jail i udostępnienia go pod FreeBSD.
Jak my nie lubimy awarii :) podstawowym problemem świadczenia usług na dużą skalę jest zapewnienie 100% ciągłości ich świadczenia, jeżeli statystycznie 1 serwer ma awarię co rok (365 dni), to przy 200 serwerach pojedyncza awaria ma prawo wystąpić co niecałe 2 dni :), problem rozszerza się jeszcze przy większej skali (Yahoo ma ponad 5 tysięcy serwerów, przy Google mówi sie o ponad 100 tysiącach serwerów - tu średni czas pomiędzy awariami to 5 minut :-).
Monitoring aktywny problem: skąd wiedzieć o padzie serwera (lub problemach z odpalonymi na nim usługami), rozwiązanie: monitoring aktywny przy użyciu testera sieci/usług (tzw. pinger), wiele lat temu stworzyliśmy własną aplikację, która pozwala monitorować serwery na poziomie IP (ping, traceroute), TCP/UDP oraz ponad 20 protokołów (HTTP, FTP, SMTP itd.), monitor pozwala zbadać jakość usługi (loguje się jako określony użytkownik, wysyła zapytania, bada treść odpowiedzi czy pasuje do wzorca, mierzy czas), w przypadku niezgodności podnoszony jest alarm w postaci SMS ów wysłanych do administratorów.
Szybki start: journaling journaling - mechanizm w systemach plików, umożliwiający zamontowanie nieprawidłowo zamkniętego fs a (np. po panicu lub awarii zasilania) bez konieczności wykonania fsck, implementacja polega na zapisywaniu 2 razy wszystkich zmian: najpierw w pliku logu a potem w docelowych miejscach filesystemu, w przypadku padu, system nanosi ponownie wszystkie zmiany znajdujące sie w pliku logu, FreeBSD nigdy nie miało obsługi journalingu, miał je za to Linux i to w kilku implementacjach (Ext3, ReiserFS, XFS, JFS).
Gjournal - konfiguracja pierwsza implementacja journalingu dla FreeBSD/UFS zrealizowana jako moduł GEOM (pracuje jako urządzenie dyskowe pod UFS em), konfiguracja: gjournal label /dev/dysk newfs -J -U2 /dev/dysk.journal mount -o async,noatime /dev/dysk.journal /mnt wpisując filesystem do /etc/fstab należy pamiętać o dodaniu do nazwy urządzenia dyskowego rozszerzenia.journal, włączenie journalingu na istniejącym fs ie wymaga osobnej partycji na journal (>= 1 GB), realizacja poleceniem gjournal + tunefs, dostępność: FreeBSD 7.0 lub patch do FreeBSD 6.2.
Zapewnienie ciągłości ważnych usług problem: zapewnienie ciągłości świadczenia ważnych usług sieciowych nawet w przypadku padu danego serwera, rozwiązanie: postawienie identycznego serwera (backup), który w przypadku awarii przejmie ruch (przejmie obsługę wskazanego adresu IP), konfiguracja - serwer master - /etc/rc.conf: cloned_interface= carp0 ifconfig_carp0= vhid 100 pass XXX A.B.C.D konfiguracja - serwer backup - /etc/rc.conf: cloned_interface= carp0 ifconfig_carp0= vhid 100 advskew 100 pass XXX A.B.C.D
backup: rsync twoim przyjacielem :) próbowaliśmy wiele metod realizacji backupu, nagrywanie na tasiemki (streamery, biblioteki taśmowe) średnio sprawuje się przy takiej ilości serwerów (problem szybkiego dostępu do danych oraz serwerów pośredniczących), znalezione rozwiązanie: grupa dużych file serwerów na macierzach SATA (> 10 TB), które cyklicznie synchronizują kopie poszczególnych maszynek przy użyciu rsync (lub rdiff-backup), rsync ściaga jedynie różnice zmian (wykrywa zmienione pliki i zmiany jakie w nich zaszły), rsync umożliwia zachowanie wersji backupu z poprzednich dni (funkcja: backup-dir).
backup: jak zrobić 10TB storage? aby stworzyć 10 TB macierz wcale nie trzeba wydać >100 KUSD na rozwiązania dużych firm, na rynku dostępne są kontrolery hardware-sata II-RAID firm 3ware (AMCC) oraz Areca na 12, 16 i 24 porty oraz obudowy serwerowe Chenbro (3U na 12 kieszeni, 4U na 16 kieszeni, 6U na 24 kieszeni), przy zastosowaniu największych dysków SATA (aktualnie 750 GB) i 24 portów, możliwe jest stworzenie macierzy o pojemności nawet 18 TB, problemem jest format tablicy partycji (MBR), który obsługuje partycje o wielkości do 2 TB, rozwiązanie: użycie macierzy bez systemu partycji (newfs -J /dev/da0.journal) + osobny dysk bootujący.
Wirtualizacja padniętej maszyny problem: zapewnienie ciągłości usług na wypadek totalnej awarii serwera, na którym nie używa się konfiguracji active-slave (carp), rozwiązanie: wystartowanie kopii uszkodzonego serwera bezpośrednio na serwerze backupu, mechanizmu używa się do czasu podniesienia uszkodzonego serwera lub wgrania ostatniej wersji backupu na nowy serwer (czas!!!), realizacja: wystartowanie specjalnej wersji plików startowych danego serwera (konfiguracja IP, wystartowanie serwerów usług) na backupie: chroot /backup/m185/current /etc/rc.home
Kernel debugger przy tak dużej ilości serwerów i usług dość często mamy okazje spotykać się z drobnymi problemami w systemie operacyjnym, wiele z nich objawia się zawieszeniem się lub wygenerowanie panica przez kernel, do analizy problemu, próby określenia warunków lub fragmentu kodu, który je powoduje używamy wbudowany w kernel FreeBSD debugger, podstawowa analiza opiera się o wynik komend: where, ps, alltrace a także kilku subwariantów polecenia show (show locks, show pmap itd), debugger ma wbudowany minihelp (komenda?).
Kernel debugger - konfiguracja w pliku konfiguracyjnym kernela: options options options options DDB KDB BREAK_TO_DEBUGGER ALT_BREAK_TO_DEBUGGER w zależności co ma się stać w przypadku panica kernela odpowiednio ustawiamy zmienne w /etc/sysctl.conf: debug.debugger_on_panic=1 debug.trace_on_panic=0 opcja BREAK umożliwia wejście do debuggera w dowolnym momencie pracy systemu (Alt-Ctrl-Esc z klawiatury lub sekwencją CR ~ ^B z portu szeregowego).
ktrace/kdump inną metodą analizy działających programów (np. serwerów usług), które czasami dziwnie się zachowują (zwracają błedy, wykonują nie prawidłowe operacji) jest monitoring wywołań syscall i (funkcji kernela) przez dany proces, włączenie monitorowania określonego procesu: ktrace -p <pid> wyświetlenie treści logu (plik ktrace.out): kdump -T istnieje także port Linuxowego strace, który ma podobne zastosowanie (ale wymaga on /proc fs a).
Jak mniej zapłacić za prąd? współczesne procesory serwerowe (wszystkie AMD Opterony, nowsze Intel Xeony) obsługują funkcję oszczędzania poboru mocy znane z wersji przeznaczonych dla notebooków, system operacyjny może dostosowywać częstotliwość pracy procesora do obciążenia, we FreeBSD stosowne API dostępne są przy pomocy urządzenia cpufreq (device cpufreq w pliku konfiguracyjnym kernela) a samym zarządzaniem zajmuje sie daemon powerd (powerd_enable= YES w /etc/rc.conf).
IdeaWebServer TAK, mamy własny serwer WWW, NIE, nie ma on nic wspólnego z Apachem (ani linijki kodu :) używamy go od ponad 9 lat (serwer ma już 12 lat), od 2 lat używamy też własnej implementacji serwera POP3, aktualnie trwają prace nad implementacją serwera SMTP, projekt nie jest i raczej nie będzie dostępny publicznie :(.
Dlaczego nie Apache? wysoka skalowalność (Apache: ~ kilkaset równoczesnych połączeń, Idea: > 10 tysięcy), większe security (Idea: uruchamianie aplikacji Klientów w jail ach, setuid/setgid do poziomu użytkownika, limitowanie cpu oraz pamięci), interfejs do pobierania/synchronizacji w czasie rzeczywistym konfiguracji serwera na bazie centralnej bazy użytkowników/serwerów, wady Idei: brak 100% kompatybilności emulacji wszystkich pseudo-standardów stworzonych przez Apacha (.htaccess, mod-rewrite itd.).
Czekamy na FreeBSD 7.0 FreeBSD 7.0 (CURRENT) zawiera kilka ciekawych z naszego punktu widzenia zmian: nowa implementacja alokatora pamięci zoptymalizowanego pod systemy wieloprocesorowe (funkcja malloc), zwiększona wydajność TCP/IP oraz sendfile, nowy scheduler dla procesorów dual-corowych, optymalizacje biblioteki wątków libthr pod zwiększenie wydajności MySQL a.
Podsumowanie jesteśmy największym użytkownikiem FreeBSD w Polsce, znamy/użytkujemy system od ponad 11 lat, wykorzystujemy wiele nowych featur w systemie, czasami sami je tworzymy (bezpośrednio lub sponsorując programistów FreeBSD), szukamy specjalistów - programistów i administratorów - efektem jest nasza obecność tu na meetbsd, zapraszamy na http://rekrutacja.home.pl.
Pytania?