Mamy aplikację, która działa na kilku (5 lub więcej i będzie rosnąć) urządzeniach. Sprzęt jest identyczny na wszystkich komputerach, a idealnie byłoby również oprogramowanie. Do tej pory zarządzałem nimi ręcznie i nie chcę już tego robić (statyczne adresy IP, wyłączanie wszystkich niezbędnych usług, instalowanie wymaganych pakietów ...). Czy ktoś może zrównoważyć zalety i wady poniższych opcji lub zasugerować coś bardziej inteligentnego?

1: Indywidualnie instaluj centos na wszystkich urządzeniach i zarządzaj konfiguracjami za pomocą chef / cfengine / puppet. Byłoby dobrze, ponieważ chciałem wymówki, aby nauczyć się korzystać z jednej z aplikacji, ale nie wiem, czy to jest rzeczywiście najlepsze rozwiązanie.

2: Zrób jedno pudełko i zrób zdjęcie. Podaj obraz za pomocą PXE i za każdym razem, gdy chcę wprowadzić modyfikacje, mogę po prostu ponownie uruchomić pola z nowego obrazu. Jak faceci z klastra normalnie radzą sobie z takimi adresami jak pliki mac w plikach / etc / sysconfig / network-scripts / ifcfg *? Używamy również infinibandu, który również nie uruchamia się, jeśli hwaddr jest nieprawidłowy. Czy można je poprawnie wygenerować przy rozruchu?

Opieram się na rozwiązaniu PXE, ale myślę, że monitorowanie za pomocą Munina lub nagios będzie nieco bardziej skomplikowane. Czy ktoś ma doświadczenie w tego typu problemach?

Wszystkie serwery mają dyski SSD i są szybkie i wydajne.

Dzięki, mat.

Twój klaster brzmi bardziej jak klaster HPC niż OLTP taki jak mój, ale myślę, że konfiguracja, której używam, też by działała. Nazywam to „mpdehaan trifecta”, ponieważ to irytujący facet, który napisał trzy narzędzia i zarządzał nimi.

1.) Cobbler do udostępniania bazy. Cobbler to projekt, który ma być skrzyżowaniem systemów kickstart, pxe, yum-repo, dhcp, dns itp. Jest to zdecydowanie najłatwiejszy sposób na uruchomienie i uruchomienie konfiguracji kickstart. W razie potrzeby możesz rozwinąć inne funkcje.

2.) Marionetka do zarządzania konfiguracją. Najlepiej, jeśli hosty zbudowane przez cobblera to bardzo proste konfiguracje, które wiedzą tylko tyle, by zadzwonić do domu na serwer lalek podczas uruchamiania. Następnie Puppet zastosuje ustawienia konfiguracji i zapewni ich spójność w całym środowisku na zawsze.

3.) Func dla poleceń ad-hoc na wielu komputerach równolegle. Na przykład „wdróż nowy kod SVN do kasy i zrestartuj apache”. Bardzo łatwo jest po prostu użyć func, aby wywołać to samo polecenie bash na grupie serwerów, podobnie jak klaster-ssh. Jeśli naprawdę chcesz się do niego dostać, możesz napisać dla niego własne moduły za pomocą naprawdę prostego pytona.

Wszystkie trzy z tych narzędzi mają dobre wiki i aktywne kanały IRC do pomocy w freenode.

Przegląd

W pewnym sensie masz tutaj dwa pytania ...

• Jak zbudować i utrzymywać standardowe serwery?
• Jak utrzymywać standardową konfigurację i wprowadzać zmiany później?

Poniżej podzieliłem moją odpowiedź, odnosząc się do tych dwóch kwestii osobno, ale są one bardzo blisko powiązane. Zajmuję się tutaj rozwiązaniami technologicznymi, a nie żadnymi z najlepszych powiązanych praktyk, takich jak kontrola zmian.

Jeśli nie obejmuje to zakresu twojego pytania, prosimy o wyjaśnienie, a ja chętnie się tym zajmę. Jest to niezbędny fundament, który ma kluczowe znaczenie dla dobrze zarządzanej infrastruktury technologicznej.

Budowanie serwerów

Nie lubię obrazów w świecie UNIX; jest to bardziej podejście oparte na stylu Windows. Wydaje się, że nawet niektórzy ludzie systemu Windows ponownie skupiają się na skryptach dla standardowych wersji.

Wydaje się, że satelita zyskuje na popularności w świecie RHEL. Spacewalk jest odpowiednikiem Open Source. Zdecydowanie musisz całkowicie wykupić podejście RHEL, aby z niego korzystać. Służy to zarówno do budowania serwerów, jak i zarządzania konfiguracją.

Najlepiej byłoby utworzyć lokalne kopie zapasowe i repozytoria na serwerze plików dla całego niezbędnego oprogramowania.

Najpierw skorzystaj z automatyzacji kompilacji dystrybucji, takiej jak Kickstart w RHEL / CentOS. Kickstart byłby linią bazową z odmianami, w zależności od potrzeb. Kompilacje Kickstart mogą być inicjowane z serwera PXE.

W przypadku bardziej zaawansowanej części kompilacji i wszystkiego, co nie było odpowiednie dla pliku Kickstart, można pisać własne skrypty. Jednak może się okazać, że lalka lub cfengine działa dobrze dla ciebie zamiast niestandardowych skryptów. Uważam, że skrypty niestandardowe są najbardziej elastyczne i nie ograniczają się do żadnego pojedynczego podejścia.

Jeśli zdecydujesz się pisać własne skrypty, polecam skrypt podstawowy do uniwersalnej konfiguracji. Byłaby to konfiguracja zabezpieczeń, hartowanie i wszystko, co dotyczy wszystkich kompilacji. Następnie ostatni skrypt do sfinalizowania roli serwera. Na przykład serwer WWW lub serwer bazy danych.

Utrzymanie standardów

To, co opisujesz, również podlega utrzymaniu konfiguracji. Standardy kompilacji, aktualizacje oprogramowania i inne rzeczy są powiązane z kompilacjami, ale na wiele sposobów są osobne.

Jeśli zdecydujesz się polegać na pakietach systemowych, a nie na tworzeniu własnych kompilacji źródłowych dla najważniejszych ról serwera, wiele z nich można utrzymać za pomocą rodzimych narzędzi systemowych. Może to być tak prosty skrypt, aby uruchomić forpętlę na liście serwerów i uruchomićyum -y update package .

W przypadku zarządzania konfiguracją to tutaj zarządzanie marionetką, cfengine i innym zarządzaniem konfiguracją w grę wchodzą narzędzia do . Są to bardzo przydatne narzędzia i zapewniają niezbędną podstawę bez pisania własnych skryptów od zera.

Podczas aktualizacji standardów konfiguracji dla serwerów ważne jest, aby wypełnić je zapasowo w standardowych kompilacjach serwerów.

Niedawno zakończyłem duży projekt wdrożenia scentralizowanego systemu kompilacji / zarządzania i konfiguracji w $ WORK. Prowadzimy CentOS.

Mój projekt, który naprawdę mi się podoba, daje nam proces kompilacji za pomocą jednego kliknięcia (no, jednej strony GUI), przy użyciu niestandardowych skryptów PHP do połączenia wszystkiego za pomocą prostego, ale skutecznego interfejsu użytkownika.

Ogólna teoria to:

1. Wykonaj wszystkie instalacje z jednego, zunifikowanego, minimalistycznego pliku KickStart (cóż, OK, jeden dla x86 i jeden dla x86-64, ale wciąż praktycznie identyczne pliki przy minimalnym wyborze pakietu).
2. KickStat poinstalacyjny skrypt ładujący Puppet.
3. Puppet stosuje całą konfigurację specyficzną dla węzła / hosta, instalację pakietu itp.

Zgadzam się, że obrazy nie są unikatowym sposobem robienia rzeczy ... są one bardziej dostosowane do świata Windows, w którym instalacja / konfiguracja skryptowa / automatyczna nie jest tak prosta.

Możesz zastąpić Puppet dowolnym innym systemem zarządzania konfiguracją, który pasuje do rachunku, ale podobało mi się deklaratywny charakter Puppet i jego koncepcja konwergencji.

Ten system zapewnia wiele korzyści:

• Puppet obsługuje wszystko po ogólnej instalacji podstawowej, więc wszystkie wymagane pakiety i konfiguracja znajdują się w jednym miejscu.
• Manifesty Lalek służą jako dodatkowe źródło dokumentacji niskiego poziomu.
• Tak długo, jak trzymasz się Puppet (tzn. Nie wprowadzasz lokalnych zmian konfiguracji lub nie łączysz ich z powrotem w Puppet), zbudowanie duplikatu maszyny jest proste.
• Ponieważ wszystkie hosty są zbudowane ze wspólnej bazy, możesz wstępnie zainstalować sprzęt lub maszyny wirtualne z zestawem pakietu podstawowego (KickStart), a następnie przekształcić je w funkcjonalne węzły, po prostu dodając klasy w razie potrzeby.
• Puppet pozwala na „oznaczanie” hostów do produkcji lub rozwoju, więc niezwykle łatwo jest zbudować kopię rozwojową / testową hosta, zaktualizować pakiety lub wprowadzić zmiany konfiguracji w razie potrzeby, przetestować, a następnie ponownie połączyć się z produkcją.

Jeśli pójdziesz ścieżką pxe, koniecznie spójrz

http://etherboot.org/wiki/index.php

GPxe zapewni większą elastyczność dzięki celom rozruchowym. Łatwo jest uruchomić system Aoe Blade i nie ma nic takiego jak uruchomienie jądra ze zdalnego serwera HTTP !!!!!!!!!! :-).

Jakiego czasu działania serwera potrzebujesz?

Nie można stworzyć idealnego obrazu, ponieważ zawsze będziesz musiał zastosować poprawki bezpieczeństwa i aktualizacje oprogramowania. Jeśli mają dostęp do Internetu, nie można po prostu zignorować łatania.

Po stronie pxe masz kilka opcji, w zależności od pliku I / O twojego klastra. Po prostu uruchom jądro i zdalnie podłącz dysk za pomocą aoe lub iscsi.

Możesz także robić bardzo sprytne rzeczy z kopiowaniem przy pisaniu obrazów. Jest świetny do aktualizacji i wycofywania wszelkich zmian, które mogą być problematyczne.

Miałem również sukces, używając root NFS, używając klastrowego rozwiązania NFS. Możesz określić różne pliki, które mają być obsługiwane, w zależności od adresów ich klientów.

Znowu musisz sprawdzić, czy twoje aplikacje lubią uruchamiać nfs. Nie nadaje się do każdego obciążenia.

klastrowany serwer NFS może zawierać 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

więc każdy klient odwołuje się do tego samego pliku, ale otrzyma plik odpowiedni dla klienta. To dość imponujące rzeczy, jednak nie jest to proste!

Wszystko to da ci szybsze czasy wdrażania, jeśli scentralizujesz system plików w pamięci sieciowej. Obrazowanie systemu operacyjnego przez sieć na zdalny dysk zajmuje dużo czasu !!!!

Jeśli korzystasz z któregokolwiek z tych rozwiązań, upewnij się, że masz dobrze zaprojektowaną i odporną na uszkodzenia warstwę sieciową oraz że twój serwer nfs / SAN jest dobrze zaprojektowany i bezpieczny!

Utrata połączenia z siecią NFS / SAN byłaby niekorzystna dla kondycji serwera. :-(

Tworzenie skryptów dla tftp / pxe jest dość łatwe do kontrolowania procesu uruchamiania.

Gdybym wiedział więcej, co tak naprawdę próbujesz zbudować, mógłbym wymyślić rozwiązanie bardziej odpowiednie dla ciebie.