Można zapytać, jak do tego doszło? Odpowiedź jest prosta. Entropia na farmie wirtualnych serwerów jest nie do uniknięcia - no chyba, że istnieje ekstremalnie ścisła polityka korporacyjna utrzymywania i uaktualniania różnych wersji OS-ów (co raczej nie jest możliwe). Jeśli pojawia się nowa wersja wybranego przez nas Linuksa, to czy natychmiast aktualizujemy go od maszyny do maszyny, zakłócając działanie aplikacji i usług, które bez tego działałyby sobie bezproblemowo przez wieczność? Jeśli Microsoft wydaje Windows Server 2012, to jak dużo czasu zajmie nam porządne przetestowanie kompatybilności wszystkich aplikacji pięknie śmigających teraz na Windows Server 2003 R2 lub 2008?

Pojawia się więc pytanie. Przy braku naturalnego cyklu życia serwera, jak szybko powinniśmy reagować, dokonując uaktualnień systemów operacyjnych na dużą skalę? Ustalają to za nas dostawcy OS-ów. To oni decydują, czy będziemy się narażać na znaczne ryzyko związane z bezpieczeństwem czy raczej porzucimy naszą dzielną VM, zastępując ją nową. Chociaż to drugie funkcjonalnie może nie mieć żadnego uzasadnienia. Jeśli posiadamy doskonale działającą lodówkę, to czy kupimy nową zaraz po tym, jak producent przestał produkować ten model?

Zobacz również:

• Akcje Intel spadają - winna rosnąca konkurencja w AI
• Wielka inwestycja Atmana w przetwarzanie danych
• AI ma duży apetyt na prąd. Google znalazł na to sposób

A jak wygląda ścieżka aktualizacji? Nasze doświadczenie z fizycznymi serwerami mówi, że najlepiej zacząć od zera. Jednak główne dystrybucje Linuksa doskonale umożliwiają skuteczną aktualizację posiadanego stanu. Ten fakt w połączeniu z możliwością zrobienia migawki obecnego stanu przed przystąpieniem do upgrade’u, sprawiają, że aktualizacja na żywym organizmie jest całkiem bezpieczną opcją. W najgorszym razie, jeśli się nie powiedzie, stracimy trochę więcej czasu. Windows nie jest tak dobrze przygotowany do tej metody, ale wciąż jest ona możliwa - backupowy plan przywrócenia stanu z migawki jest w tym przypadku niezbędny.

Jednak okazuje się, że im więcej robimy aktualizacji OS na tej samej instancji serwerowej tym bardziej staje się ona niepewna (zakładając nawet, że upgrade ma wsparcie techniczne). Dziwne rzeczy mogą się dziać. Błędy w przyszłych uaktualnieniach z powodu osieroconych pakietów lub dawnych zmian. Problemy przyszłych aplikacji lub uaktualnień - przez niespodzianki aktualizowania instancji z OS-a wydanego pięć, a nawet osiem lat temu.

Krótko mówiąc, aktualizowanie jest większym hazardem niż po prostu pozostawienie spraw samym sobie. W czasie, gdy budżety IT się kurczą, a personelu ciągle jest za mało, planowanie i wykonanie świeżych instalacji i migracji usług dla wszystkich tych VM staje się jedną z prac Herkulesa. W wielu wypadkach te serwery - choć osierocone - będą działały doskonale i bezbłędnie.

Oczywiście, są z tym związane różne poziomy zagrożenia. Publicznie dostępne serwery będą wymagały więcej uwagi niż całkowicie wewnętrzne maszyny, choć i te drugie nie mogą zostać całkowicie zaniedbane. Jeśli mamy wewnętrzną linuksową instancję VM z uruchomionymi kilkoma aplikacjami webowymi, to poprawki bezpieczeństwa dla BIND-a nie będą aż takie krytyczne. Jeśli jednak mamy publiczny serwer DNS i pojawia się poważny problem z bezpieczeństwem, to ważne jest byśmy byli z aktualizacjami na bieżąco.

Inaczej rzecz ujmując, sprowadza się to do budżetu i czujności. Jeśli budżet w odniesieniu zarówno do czasu pracy i kosztów licencji jest taki, że można myśleć o ścisłym rygorze uaktualnień, to zmarnujemy dużo wysiłku, ale nasze VM będą świeżutkie. Jeśli nie mamy na to budżetu - scenariusz bardziej prawdopodobny - musimy czujnie obserwować naszą gromadę nieśmiertelnych serwerów.