Wprowadzenie do AIX dla administratorów Linux - part1

Wstęp

Często spotykam się z ciekawością administratorów Linux odnośnie tego, jak wygląda administracja systemem AIX i jak bardzo różni się od tego co już znają. Większość specjalistów ma świadomość tego, że Linux wywodzi się z Unixa, ale wielu z nich przynajmniej raz zastanawiało się, na ile ich wiedza i doświadczenie miałyby przełożenie na pracę z systemem takim jak AIX. Część z nich miało również okazję np. zalogować się do systemu AIX i wykonywać podstawowe operacje administracyjne, ale nie miało pewności na ile znane im już komendy mają odzwierciedlenie w nowym środowisku i czy mają takie samo zastosowanie.

Jak wiadomo, zetknięcie się z czymś nowym, może wiązać się z całym wachlarzem emocji, począwszy od fascynacji, aż po frustrację i lęk przed nieznanym.

Myślę, że przy nauce każdej technologii warto mieć otwarty umysł i nie zniechęcać się różnicami już na samym początku. O ile uważam, że podważanie istniejących rozwiązań i konstruktywna krytyka jest niezwykle istotna w pracy w IT, to jednak zachęcam do luźnego podejścia, przynajmniej na samym początku nowej drogi :). Zdecydowanie nie warto prowadzić wojny, który system jest lepszy, a zamiast tego warto skupić się na tym, które podejście lepiej się sprawdzi w danym zastosowaniu.

Świat AIX jak i Linux często się przenika, nie tylko przez samą technologię, ale również przez przyzwyczajenia administratorów, którzy mają do czynienia z tymi systemami i szukają odpowiedników swoich ulubionych narzędzi. Przykładowo, wielu administratorów Linux korzysta z narzędzia NMON, ale nie wie o tym, że pierwotnie został on napisany na system AIX i już od wielu lat jest jego częścią. Dość powszechne jest też używanie LVM na Linux, ale mało kto zdaje sobie też sprawę, że LVM pojawił się pierwszy raz właśnie w AIX i to już w roku 1989, czyli już około 10 lat wcześniej, przed Linuxem. Co ciekawe, AIX był też pierwszym systemem operacyjnym, gdzie został zaimplementowany journaling. Z kolei dzięki administratorom Linux i ich przyzwyczajeniem do ulubionych narzędzi, dla AIX istnieje i rozwija się dedykowane repozytorium narzędzi OpenSource (AIX Toolbox for Open Source Software), które adresuje problem braku części oprogramowania w standardzie.

Początkowo planowałem napisać jeden artykuł, ale po rozpisaniu wątków, które wydały mi się istotne lub ciekawe, okazało się że jest tego zbyt dużo jak na jedną publikację, dlatego postanowiłem podzielić ją przynajmniej na trzy osobne części.

Tekst jest skierowany konkretnie do administratorów Linux, ale jeśli nie czujesz się adresatem lub interesuje Cię AIX na poziomie ogólnym, zachęcam Cię do zapoznania się z innymi moimi publikacjami:

Garść informacji na początek

Warto podkreślić że:

Linux wywodzi się z Unix (ale nie jest Unixem)
AIX jest jednym z systemów z rodziny Unix

Choć sam Linux to tak naprawdę jedynie kernel systemu, a system operacyjny to cała dystrybucja Linuxa, przyjęło się w potocznym języku mawiać o Linuksie jako systemie operacyjnym.

Znane są systemy Linuxowe zarówno darmowe, jak i komercyjne, ale jeśli już porównywać je do AIX-a, najbliżej byłoby mu do systemów takich jak Red Hat Enterprise Linux oraz SUSE Linux Enterprise Server, dlatego że są to systemy klasy enterprise, przeznaczone typowo do zastosowań serwerowych.

System AIX jest od samego początku rozwijany przez IBM, a jego początki sięgają już roku 1986. AIX jest systemem komercyjnym i licencjonowanym, a na dzień pisania tego tekstu nie istnieje darmowa edycja tego systemu – tu już mamy pierwszy ważny powód dlaczego jest tak mało znany w porównaniu do Linuxa. Jest to system dedykowany do zastosowań serwerowych i tylko dla serwerów IBM Power. Czy w takim razie na serwerach IBM Power może działać tylko AIX? Nie, ponieważ na serwerach IBM Power oprócz AIX-a może działać również system „IBMi” (dawniej znany jako OS/400 i i5/OS) oraz systemy…. Linux, m.in. RHEL, SLES, a nawet Ubuntu.

Wiele osób może zadać sobie pytanie, po co ten AIX jeśli na tych serwerach można uruchomić Linuxa?

Warto zdawać sobie sprawę z tego, że AIX jest od początku tworzony dla serwerów Power, a więc jest w pełni kompatybilny z tą platformą sprzętową. Prawdopodobieństwo tego, że system operacyjny i sprzęt od jednego producenta będą działać ze sobą najlepiej, jest z pewnością znacznie wyższe niż w przypadku systemu rozwijanego przez firmy zewnętrzne lub społeczność. Architektura procesorów Power jest związana też ze specyficznymi cechami (takimi jak m. in. obsługa aż 8 wątków na rdzeń procesora), których nie ma architektura x86. Czy zawsze AIX jest najlepszym wyborem dla serwerów IBM Power? Nie, dlatego że jak zawsze wszystko zależy od konkretnego zastosowania. Z pewnością AIX będzie świetny w przypadku takich baz jak np. Oracle, Informix, DB2, ale już np. bazy OpenSource jak np. PostgreSQL czy MariaDB prawdopodobnie będą miały np. częściej wydawane nowe wersje dla Linux i większe wsparcie społeczności. W wielu scenariuszach może być tak, że na Linuxa na serwerze Power, łatwiej będzie zmigrować aplikację/bazę z takiej samej dystrybucji Linux na x86 (np. RHEL 9.4 x86/ppce64le).

Jeżeli chcesz poznać system AIX od strony praktycznej, potrzebujesz serwera IBM Power lub dostępu do niego w chmurze (np. PowerVS). Uruchomienie go na domowym laptopie lub maszynie wirtualnej na domowym labie niestety raczej nie wchodzi w grę.

Warto wiedzieć, że zarówno system AIX jak i Linux, na nowych serwerach Power, będą działać w ramach maszyn wirtualnych, znanych najczęściej LPAR–ami (LPAR – Logical Partition) lub Partycjami.

Wirtualizacja jest nieodzownym elementem platformy Power i system działający jako Bare Metal spotyka się bardzo rzadko, do specyficznych zastosowań. W zdecydowanej większości przypadków Linux lub AIX na IBM Power będzie działać jako wydzielona zwirtualizowana część serwera, czyli jako maszyna wirtualna.

Architektura IBM Power

O ile systemy linuxowe możemy uruchamiać na różnych architekturach procesora (nie tylko x86, ale również na Power w architekturze ppc64le) to system AIX został zaprojektowany dla pracy na serwerach z procesorami IBM POWER i oficjalnie nie ma wsparcia dla uruchomienia go na architekturze x86 (choć niektórym entuzjastom udało się w ramach ciekawostki uruchomić na x86 z emulacją ppc64 na qemu).

W kontekście samych serwerów Power i wirtualizacji PowerVM, odsyłam do mojej innej publikacji: https://www.linkedin.com/pulse/discover-power-ibm-wirtualizacja-powervm-michal-wiktorek-k0faf

Istotną różnicą jest to, że nowe wersje dystrybucji takich jak Red Hat Enterprise Linux lub SUSE Enterpise Server są głównie publikowane na architekturę ppc64le. Kiedyś były wydawane również na ppc64 (Big Endian), ale teraz jest to już zdecydowanie rzadkość i nowe wersje systemów Linux są wydawane przede na ppc64le, przy czym w systemie Debianie używana jest nazwa ppc64el.

Czym się różnią od siebie ppc64le od ppc64?

W skrócie ppc64 to standard Big Endian, a ppc64le to Little Endian (stosowany w architekturze x86) i chodzi o kolejność bitów (endianess). Po szczegóły odsyłam do strony: https://www.ibm.com/support/pages/just-faqs-about-little-endian

Serwery IBM Power pozwalają na pracę w obydwu trybach (od generacji Power8). Co ciekawe nie musimy decydować się na konkretny tryb dla całego maszyny fizycznej i wymuszać jednego trybu dla wszystkich LPAR-ów na nim działających. Big Endian i Little Endian, może być niezależne dla różnych LPAR-ów co jest unikatową cechą serwerów IBM Power, dlatego określa się te serwery jako bi-Endian.

Dlaczego nie ma jednego standardu? Big Endian był w serwerach IBM Power od początku, a obsługa trybu Little Endian, to w mojej opinii tak naprawdę ukłon IBM dla klientów, którzy chcą migrować lub integrować systemy z x86 na serwery Power – dzięki temu nie jest potrzebna konwersja kolejności bitów np. przy importowaniu baz danych.

Komendy, zgodność z POSIX i shell

Standard POSIX powstał jako inicjatywa mająca na celu ujednolicenie interfejsów systemów operacyjnych, po to by zapewnić przenaszalność oprogramowania pomiędzy różnymi platformami. Powstanie POSIX było odpowiedzią na tzw. „wojny Uniksów”, kiedy to różni producenci wprowadzali własne, niekompatybilne ze sobą wersje systemów, co utrudniało pracę programistom.

Choć Linux nie jest Unixem, to jest częściowo zgodny ze standardem POSIX. Oznacza to m.in., że wiele poleceń shellowych będzie działać zarówno na systemach Unix (w tym na AIX) jak i na Linux. Po przykłady takich poleceń odsyłam do wikipedii: https://en.wikipedia.org/wiki/List_of_POSIX_commands

W praktyce oznacza to, że osoba biegła w Linux, przy pierwszym zalogowaniu do AIX-a będzie mogła wykonać wiele podstawowych poleceń, np. związanych z operacjami na plikach, takich jak cat, ls, cd, cp, mv, rm, chmod, chown i wiele innych. Warto wiedzieć jednak, że polecenia te nie zawsze będą działać identycznie. Przykładowo, chociaż polecenie grep należy do standardu POSIX, to w większości dystrybucji Linux jest używana jego odmiana „GNU grep”, w związku z czym istnieją różnice np. jeśli chodzi o parametry do polecenia. Podobnie sprawa wygląda np. z AWK, ponieważ w Linux jest to GNU AWK (gawk), a samo polecenie awk jest zazwyczaj aliasem lub linkiem do gawk.

Z pewnością znajomość Linux w poznawaniu AIX jest pomocna, jednak warto być uważnym i nie zakładać z góry, że każda komenda zadziała w ten sam sposób. Niekiedy wymaga to walki z przyzwyczajeniami. Często polecenia w Linux mają parametr „-h” czyli „human-readable”, np. du -h lub df -h. W AIX parametry do tych poleceń nie zadziałają, a zamiast tego konieczne będzie podanie parametru odzwierciedlającego jednostkę, czyli np. du -m/du -g lub df -m/df -g (odpowiednio w megabajtach/gigabajtach).

Z nauką nowego systemu jest trochę jak z nauką nowego języka – z jednej strony podobieństwa pomagają, a z drugiej strony łatwo o nieporozumienie gdy zakłada się z góry, że znaczenie jakiegoś słowa jest takie samo w obu językach, jak np. słowo „pants” w amerykańskiej i brytyjskiej odmianie angielskiego 🙂

Przykładowo, halt na Linux powinno zatrzymać system w trybie „gracefully”, ale na AIX to polecenie zadziała brutalnie, niczym odłączenie serwera z prądu. Podobnie się ma sprawa z poleceniem reboot.

Jeśli potrzebujesz zatrzymać system AIX w „ładny” sposób użyj polecenia shutdown -F lub shutdown -Fr do restartu.

To co może zniechęcać przy pierwszym zetknięciu z AIX to powłoka ksh czyli Korn Shell. Przyjmuje się że Korn Shell jest wydajniejszy od basha, ale jest też mniej popularny i dla administratorów Linux używanie go może być problematyczne, zwłaszcza na początku.

Jeśli nie możesz żyć bez basha, możesz go również używać jako powłoki. Od AIX w wersji 7.3 bash jest dostarczany wraz z systemem, a dla starszych można go doinstalować z repozytorium AIX Toolbox for Open Source Software. Należy jednak pamiętać, że ksh ma największa kompatybilność z AIX i zdecydowanie zalecam pisać skrypty w ksh, jeśli chcesz mieć większą pewność, że będą działać poprawnie. Aby korzystać z ksh bardziej komfortowo, polecam skorzystać z polecenia:

set -o vi

Pozwoli to na korzystanie z shella za pomocą komend vi (w tym np. szukanie poprzednich komend z pomocą klawiszy h/j/k/l tak jak strzałek w bashu), a uzupełnianie ścieżek plików zamiast klawisza tab może być wykonywane za pomocą ESC+\

Jeśli nie znasz jeszcze obsługi edytora Vi, zdecydowanie zalecam nauczyć się jego podstaw, choćby dlatego, że powinien być standardowo w zdecydowanej większości systemów Unix/Linux – dobrze jest więc znać edytor, który jest bardzo uniwersalny i dostępny na wielu różnych systemach operacyjnych.

Warto zwrócić uwagę, że polecenie vi jest często na Linux tak naprawdę aliasem lub linkiem symbolicznym do polecenia vim ale nie jest to ten sam edytor.

Oprogramowanie OpenSource

Wspomniałem już, że na Linux korzysta się narzędzi takich jak grep, awk, sed itp. z wersji GNU. Czy oznacza to, że jest się skazanym w AIX tylko na te narzędzia zgodne z POSIX? Na szczęście nie. Narzędzia te oraz wiele, wiele innych przydatnych narzędzi często używanych na Linux (m.in. ncdu, mc, netperf, tmux, screen) można doinstalować z repozytorium AIX Toolbox for Open Source Software. Listę pakietów można sprawdzić na stronie repozytorium:

https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads-alpha

Chociaż dla AIX, standardowym pakietem oprogramowania jest Fileset (o czym więcej będzie w kolejnym artykule z tego cyklu), to pakiety Open Source, są w formacie RPM (.rpm) znanym m.in. z Fedora, RHEL, CentOS i SLES. Instalację i zarządzanie pakietami rpm w AIX, najlepiej jest wykonywać za pomocą narzędzia dnf, czyli analogicznie jak w systemie RHEL, Fedora itp.

dnf install ncdu

Pakiety instalują się do lokalizacji /opt/freeeware, więc nie musimy się martwić że np. gawk nadpisze nam oryginalny /usr/bin/awk

Warto zwrócić uwagę na to, że w repozytorium AIX Toolbox for Open Source są nie tylko narzędzia, ale również bazy danych, takie jak MariaDB lub PostgreSQL oraz środowiska programistyczne Python, Ruby, Rust itp.

SMIT

Pisząc o AIX, nie sposób nie wspomnieć o SMIT, (System Management Interface Tool) czyli interaktywnym narzędziu dostępnym z poziomu CLI, które pozwala wykonywać wiele rzeczy związanych z konfiguracją systemu AIX. Jest szczególnie przydatne dla początkujących administratorów, ale używają go również zaawansowani. Korzystanie ze SMIT-a pozwala uniknąć błędów w postaci literówek, wykonać czynność bez znajomości konkretnego polecenia i jest też bardzo wygodne. Z poziomu narzędzia SMIT można wykonać całe mnóstwo czynności związanych z zarządzaniem i utrzymaniem systemu operacyjnego, wybierając strzałkami na klawiaturze odpowiednie menu,podmenu i pozycje z list.

Osoby, które administrowały systemem SUSE Enterprise Linux Server może się ono kojarzyć z narzędziem YaST.

Niezwykle przydatną funkcją w SMIT jest możliwość podejrzenia polecenia dla wykonywanej czynności w danym podmenu za pomocą kombinacji klawiszy ESC+6 (lub F6), dzięki czemu możemy zweryfikować co dokładnie zostanie wykonane lub poznać sposób na wykonanie czynności za pomocą CLI.

Uruchomienie narzędzia odbywa się poprzez wykonanie polecenia smit lub smitty, ale można wywołać też odpowiednie menu używając skrótu, np. smit lvm by przejść bezpośrednio do ustawień LVM, lub smity chvg by przejść do modyfikacji Volume Group.

To już koniec części pierwszej 🙂

W kolejnych publikacjach z tego cyklu planuję poruszyć m.in. kwestię różnic w pracy z urządzeniami, LVM, ODM, zarządzania pakietami oprogramowania, bootloadera i maintenance mode, narzędzi do zabezpieczania systemu i DevOps.