„Czy możemy uaktualnić nasze istniejące produkcyjne serwery EL5 do EL6?”

Prosto brzmiące żądanie od dwóch klientów z całkowicie różnych środowisk skłoniło moją zwykłą najlepszą praktykę do odpowiedzi „tak, ale będzie to wymagało skoordynowanej przebudowy wszystkich systemów ” ...

Obaj klienci uważają, że całkowita przebudowa ich systemów jest niedopuszczalną opcją ze względu na przestoje i zasoby ... Na pytanie, dlaczego konieczna jest pełna ponowna instalacja systemów, nie znalazłem dobrej odpowiedzi poza tym, „tak to jest ... ”

Nie próbuję uzyskać odpowiedzi na temat zarządzania konfiguracją („Puppetize all ” nie zawsze ma zastosowanie ) lub tego, jak klienci powinni lepiej planować. Jest to rzeczywisty przykład środowisk, które rozwinęły się i rozwijały w zakresie zdolności produkcyjnych, ale nie widzą czystej ścieżki do przejścia do następnej wersji swojego systemu operacyjnego.

Środowisko A:
organizacja non-profit z 40 x Red Hat Enterprise Linux 5.4 i 5.5 serwerami baz danych i serwerów pocztowych, działającą aplikacją Java, programami równoważącymi obciążenie oprogramowania i bazami danych Postgres. Wszystkie systemy są wirtualizowane w dwóch klastrach VMWare vSphere w różnych lokalizacjach, każdy z HA, DRS itp.

Środowisko B:
firma finansowa o wysokiej częstotliwości z systemami 200 x CentOS 5.x w wielu obiektach kolokacyjnych prowadząca operacje handlu produkcją, wspierająca wewnętrzny rozwój i funkcje back-office. Serwery transakcyjne działają na sprzęcie z surowym serwerem towarowym. Mają liczne sysctl.conf, rtctlprzerywające wiązanie i poprawki sterowników w celu zmniejszenia opóźnień przesyłania komunikatów. Niektóre mają niestandardowe i / lub jądra w czasie rzeczywistym. Na stacjach roboczych deweloperów działają również podobne wersje CentOS.

W obu przypadkach środowiska działają bezproblemowo. Chęć aktualizacji wynika z potrzeby nowszej aplikacji lub funkcji dostępnej w EL6.

• Dla firmy non-profit jest ona powiązana z Apache, jądrem i niektórymi rzeczami, które sprawią radość programistom.
• W firmie handlowej chodzi o pewne ulepszenia jądra, stosu sieciowego i GLIBC, które zadowolą deweloperów.

Obie są rzeczami, których nie można łatwo spakować ani zaktualizować bez radykalnej zmiany systemu operacyjnego .

Jako inżynier systemów doceniam, że Red Hat zaleca pełne przebudowy podczas przechodzenia między głównymi wydaniami wersji. Czysty start zmusza do refaktoryzacji i zwracania uwagi na konfiguracje po drodze.

Będąc wrażliwym na potrzeby biznesowe klientów, zastanawiam się, dlaczego jest to tak uciążliwe zadanie . System pakowania RPM jest w stanie obsłużyć uaktualnienia na miejscu, ale dostają się małe szczegóły: /bootwymagające więcej miejsca, nowe domyślne systemy plików, RPM prawdopodobnie zepsute w połowie uaktualnienia, przestarzałe i niedziałające pakiety ...

Jaka jest tutaj odpowiedź? Inne dystrybucje (oparte na .deb, Arch i Gentoo) wydają się mieć tę zdolność lub lepszą ścieżkę. Powiedzmy, że znajdujemy przestoje, aby wykonać to zadanie we właściwy sposób:

• Co powinni zrobić ci klienci, aby uniknąć tego samego problemu, gdy EL7 zostanie wydany i ustabilizuje się?
• Czy jest to przypadek, w którym ludzie muszą zrezygnować z pełnej przebudowy co kilka lat?
• Wygląda na to, że pogorszyło się wraz z ewolucją Enterprise Linux ... A może po prostu sobie to wyobrażam?
• Czy to zniechęciło kogoś do korzystania z systemów operacyjnych Red Hat i pochodnych?

Podejrzewam, że istnieje kąt zarządzania konfiguracją, ale większość instalacji Puppet, które widzę, nie przekładają się dobrze na środowiska z wysoce spersonalizowanymi serwerami aplikacji ( środowisko B może mieć pojedynczy serwer, którego ifconfigdane wyjściowe wyglądają tak ). Chciałbym usłyszeć sugestie, w jaki sposób można wykorzystać zarządzanie konfiguracją, aby pomóc organizacjom w pokonaniu poważnej wersji wersji RHEL.

(Nota autora: Ta odpowiedź dotyczy RHEL 6 i wcześniejszych wersji. RHEL 7 ma teraz w pełni obsługiwaną ścieżkę aktualizacji z RHEL 6, której szczegóły znajdują się na końcu.)

Na początek należy zauważyć, że istnieją dwa sposoby aktualizacji na miejscu:

1. Wrzuć instalacyjny dysk DVD (lub użyj obrazu DVD przez iLO / iDRAC), uruchom go z niego i wybierz Uaktualnij, np linux upgradeany.
2. Zaktualizuj redhat-releaseRPM ręcznie, uruchom yum distro-sync(jest to nieco uproszczone) i uruchom ponownie.

Metoda 1 jest po prostu nieobsługiwana. Metoda 2 dotyczy prawdziwych kowbojów. Oprócz zalecanych świeżych instalacji, zrobiłem oba te ...

Czy potrzebuję wsparcia?

Wsparcie ma dwa uzupełniające się znaczenia w naszym świecie. Po pierwsze, produkt ma określoną funkcję (np. „Postfix obsługuje SMTP”). Po drugie, sprzedawca porozmawia o tym z tobą. Która definicja nie zawsze jest jasna z kontekstu.

Aby wykonać zadanie, oczywiście potrzebujesz wsparcia w pierwszym sensie. Pomoc techniczną dostawcy stanowi pomoc w rozwiązywaniu problemów i udzielanie dostawcy informacji zwrotnych na temat tego, jakie funkcje muszą istnieć lub zostać ulepszone. Wiele witryn płaci fortunę za wsparcie dostawcy, gdy dysponuje wewnętrzną wiedzą specjalistyczną, aby rozwiązać wszelkie pojawiające się problemy, szybciej, a nawet taniej niż sprzedawca. To, czy zakup wsparcia dla dostawcy jest ostatecznie decyzją biznesową, będziesz musiał podjąć (lub doradzić zarządowi).

Dlaczego nie przeprowadzić aktualizacji na miejscu?

Tak mówi o tym Red Hat :

Red Hat nie obsługuje uaktualnień w miejscu między głównymi wersjami Red Hat Enterprise Linux. Wersja główna jest oznaczona zmianą wersji liczb całkowitych. Na przykład Red Hat Enterprise Linux 5 i Red Hat Enterprise Linux 6 są głównymi wersjami systemu Red Hat Enterprise Linux.

Uaktualnienia w miejscu w głównych wersjach nie zachowują wszystkich ustawień systemu, usług lub niestandardowych konfiguracji. W związku z tym Red Hat zdecydowanie zaleca świeże instalacje podczas aktualizacji z jednej głównej wersji do drugiej.

Ponadto ostrzegają:

Pamiętaj jednak o następujących ograniczeniach, zanim zdecydujesz się na aktualizację systemu:

• Poszczególne pliki konfiguracyjne pakietów mogą, ale nie muszą działać po aktualizacji z powodu zmian w różnych formatach lub układach plików konfiguracyjnych.
• Jeśli masz zainstalowany jeden z warstwowych produktów Red Hat (taki jak Cluster Suite), może być konieczne jego ręczne uaktualnienie po zakończeniu aktualizacji Red Hat Enterprise Linux.
• Aplikacje innych firm lub niezależnych dostawców oprogramowania mogą nie działać poprawnie po aktualizacji.

Oczywiście opisują następnie, jak wykonać uaktualnienie w miejscu za pomocą metody 1, na wypadek, gdyby naprawdę tego chcesz. Funkcja istnieje, a Red Hat poświęca na to czas programowania, więc jest obsługiwany, ponieważ funkcja istnieje. Ale jeśli coś pójdzie nie tak, Red Hat powie ci, aby zainstalować świeżo; nie zapewnią wsparcia dostawcy dla rzeczy, które ulegną awarii w wyniku aktualizacji.

Dla przypomnienia, nigdy nie miałem problemu z uaktualnieniem na miejscu systemu RHEL / CentOS lub Fedora, którego sam nie mogłem rozwiązać. Typowe problemy wynikają z pakietów o zmienionych nazwach, repozytoriów stron trzecich i sporadycznych niezgodności wersji między architekturami pakietu i386 i x86_64. yumMyślę, że instalator jest nieco lepszy w obsłudze .

Jak powinienem zaktualizować?

Ogólnie ostrzegam ludzi, że powinni planować okres konserwacji co 3-4 lata, aby zaktualizować systemy RHEL z jednej głównej wersji do następnej. Podczas gdy aktualizacje zwykle przebiegają płynnie, nieoczekiwane zawsze mogą się zdarzyć.

W obu środowiskach spodziewam się, że uaktualnienie w miejscu będzie działać, ale zdecydowanie zalecamy najpierw przetestowanie go dokładnie. P2V reprezentatywna próbka serwerów i uruchom aktualizację lokalną w systemach wirtualnych, aby zobaczyć, jakie problemy napotkasz. Następnie możesz zaplanować faktyczne uaktualnienie produkcji w oparciu o lepszą wiedzę o tym, co się wydarzy.

W przypadku dużego wdrożenia, takiego jak tutaj, rozważ zastosowanie podejścia Limoncelli „jeden-kilka-wielu”. Uaktualnij jedną maszynę, zobacz, jakie problemy występują, rozwiąż je, a następnie skorzystaj z lekcji nabytych podczas uaktualniania małej partii maszyn, powtórz zdobytą wiedzę, a następnie, gdy uważasz, że wszystkie załamania zostały wypracowane, uaktualnij ich duże partie.

W takim czasie zalecam również dokładne przyjrzenie się procesowi wdrażania aplikacji. Jeśli nie jest wystarczająco zautomatyzowany, aby można go było uruchomić za pomocą jednego polecenia i mieć wystarczającą pewność, że aplikacja zostanie poprawnie wdrożona, być może programiści muszą zacząć nad tym pracować. Posiadanie takiego procesu wdrażania znacznie ułatwiłoby świeżą instalację nowszej wersji EL, a następnie wdrożenie na niej.

Czy zmiana dystrybucji pomoże?

Dystrybucje oparte na Debianie mają obsługiwaną metodę uaktualniania w miejscu i przeważnie działa, ale nie jest odporna na problemy. Na przykład wiele osób zepsuło się z wersji Ubuntu 10.04 LTS do 12.04 LTS za pomocą obsługiwanej metody. Nie jest jasne, czy Debian lub Canonical poświęcają wystarczającą ilość czasu na „wsparcie” tej funkcji, tj. Upewnienie się, że działa. I nadal musisz kupić wsparcie dla tej dystrybucji, jeśli chcesz, żeby ktoś trzymał cię za rękę. Wątpię więc, byś dużo zyskał na przejściu na taki rozdział.

Możesz zyskać, przechodząc na dystrybucję kroczącą, taką jak Gentoo lub Arch. Jednak to również nie czyni cię odpornym na problemy; oznacza to po prostu, że musisz stale rozwiązywać problemy z aktualizacją przez cały okres eksploatacji serwera (np. za każdym razem, gdy ty lub programiści zdecydujecie się zaktualizować coś w systemie), a nie wszyscy naraz w dobrze zaplanowanym czasie aktualizacji dystrybucji. Nie masz również dostawcy zapewniającego wsparcie.

Co przyniesie przyszłość?

Projekt Fedora pracuje nad narzędziem do poprawy uaktualnień w miejscu. Mieli narzędzie o nazwie, preupgradektóre zostało porzucone i zastąpione nowym narzędziem o nazwie fedup, począwszy od Fedory 18 . Zostało to dodane do RHEL7 i teraz aktualizacje na miejscu mają pełne wsparcie , przynajmniej od RHEL 6 do RHEL 7 . Z własnego doświadczenia mogę powiedzieć, że chociaż fedupwciąż ma pewne załamania , kształtuje się, aby być bardzo przydatnym narzędziem.

CentOS eksperymentuje również z repozytorium typu „ roll -release” , ale dotyczy to tylko mniejszych wersji (np. 6.3-6.4).

Moje zdanie na temat ostatniego akapitu:

Podejrzewam, że istnieje kąt zarządzania konfiguracją, ale większość instalacji Puppet, które widzę, nie przekładają się dobrze na środowiska z wysoce spersonalizowanymi serwerami aplikacji (środowisko B może mieć pojedynczy serwer, którego dane wyjściowe ifconfig wyglądają tak). Chciałbym usłyszeć sugestie, w jaki sposób można wykorzystać zarządzanie konfiguracją, aby pomóc organizacjom w pokonaniu poważnej wersji wersji RHEL.

Myślę, że prawdziwą wartością systemów zarządzania konfiguracją, szczególnie w kontekście środowiska B, jest to, że zapewniają one narzędzia do budowy usługi niezależnie od serwerów, które ją obsługują. Jeśli CMS nie został użyty do stworzenia istniejących usług, prawdopodobnie nie pomoże to zbytnio w odtworzeniu usług.

Wiem, że to nie rozwiązuje twojego bezpośredniego problemu, ale dla mnie wynika to z myślenia organizacji w kategoriach serwerów, a nie usług. W myśleniu skoncentrowanym na usługach osobowość poszczególnych serwerów nie musi być utrzymywana, dopóki usługa będzie działać. Jeśli CMS jest używany w zdyscyplinowany sposób do zbudowania całej usługi, wówczas przeniesienie tej usługi do innego systemu powinno być stosunkowo proste, ponieważ cała osobowość maszyny zostanie zbudowana przez CMS.

PS Nie jestem do końca pewien, co jest znaczące w wyjściu ifconfig w tym kontekście - jest on generowany przez plik konfiguracyjny i niektóre skrypty (w przeciwnym razie nie byłoby go przy rozruchu), a w razie potrzeby można nimi zarządzać przez CMS.