„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
, rtctl
przerywają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: /boot
wymagają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 ifconfig
dane 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.
yum
, który działał dla mnie przez większość czasu. Mam tylko nadzieję, że RH podjęły ogromne uderzenie kija bólu od swoich klientów płacących za ich decyzji nie mieć obsługiwany upgrade'u 5-> 6, i przemyśleć to dla 6-> 7.upgradeany
parametru czasu rozruchu, tak? Testowałem go dwa razy, raz na czystej instalacji C5, gdzie działał dobrze; kiedyś na (testowej kopii) crufty old „kiedyś był C4 i został uaktualniony”, instalując tam, gdzie drastycznie zawiodła.*-release files
i wszystko). Ale pytania zadane w tym tygodniu przez klientów sprawiły, że zastanowiłem się więcej nad tym, jak zakorzenione może być środowisko dzięki konkretnej wersji, i nie mam wyjścia.Odpowiedzi:
(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:
linux upgradeany
.redhat-release
RPM ręcznie, uruchomyum 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 :
Ponadto ostrzegają:
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.
yum
Myś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,
preupgrade
któ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żfedup
wciąż 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).
źródło
Moje zdanie na temat ostatniego akapitu:
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.
źródło