Download: SysadminPoznan

KNOW HOW
Linux na mainframe
Linux na mainframe
HISTORIA WDROŻENIA
NA UNIWERSYTECIE W POZNANIU
Niniejszy artykuł stanowi próbę podsumowania historii instalacji Linuksa na komputerze typu mainframe na
Uniwersytecie im. Adama Mickiewicza w Poznaniu, dokonaną przez uczestnika wdrożenia, Piotra Kolasińskiego.
PIOTR KOLASIŃSKI
Początek
N
a początku były dinozaury...
No, niezupełnie – tak naprawdę to były pudła. Dwie wielkie
skrzynie i problemy z przeciśnięciem
przez drzwi. Potem było już dużo... łatwiej, oczywiście.
Stan faktyczny: komputer, macierz
i kilka osób reprezentujących dwa odrębne światy: Linux/uczelnia i mainframe/
biznes. Najpierw konfiguracja podstawowa: po pierwotnym uruchomieniu przez
personel techniczny IBM (kabelkologia
i mikrokody) przyszedł czas na konfigurację I/O. Nie mam na myśli bynajmniej
dobierania karty graficznej, sterownika
dysków itp. Tak naprawdę trzeba zdecy-
68
NUMER 15 KWIECIEŃ 2005
dować, jak podzielić macierz – mieliśmy
do dyspozycji 2 * 1 TB i przestrzeń 512
(2 * 256) urządzeń logicznych. Minimalny przydział obszaru – 1 cylinder (ok. 15 *
56 kB), maksymalny – 32760 cylindrów.
Standardy są najlepsze, więc pierwsza decyzja – 16 dysków w klasycznym układzie
3390-3 (3339 cylindrów każdy). Kilka
operacji na konsoli „rekinka” (pracującej
pod kontrolą Linuksa) i rozpoczyna się
proces formatowania macierzy i przydziału urządzeń. O pozostałej puli z pierwszego terabajta zdecydujemy później (to
przecież mainframe – system zobaczy nowe logiczne dyski bez restartu). Teraz pora na „czarne maleństwo”. Spojrzenie
oczami inżyniera elektronika daje następujący obraz: 6 interfejsów sieciowych
(dwa miedziane GbE i cztery światłowo-
WWW.LINUX-MAGAZINE.PL
dowe), 4 interfejsy FICON, 8 GB pamięci
i dwa procesory. Dla administratora to
już coś innego – zaczyna od pytania, ile
partycji i ile pamięci w każdej z nich.
Operacja konfiguracji generalnie może
przebiegać „na gorąco” – z jednym wyjątkiem – zmiana ilości partycji wymaga ponownego startu całości (tzw. proces POR
– „Power On Reset"). Wszyscy przechodzimy do innego pomieszczenia: stół, kawa, kartki, ołówki. Po chwili dochodzą
jeszcze kolorowe flamastry. Po dwóch godzinach z wielu możliwych wariantów
wyłania się pierwsza konfiguracja.
Pozostajemy przy trzech partycjach,
jedno z miedzianych połączeń pozostaje
klasyczną kartą sieciową, a drugie na potrzeby systemu z/VM ma być ustawione w trybie emulacji terminali 3270.
Linux na mainframe
Po wstępnej instalacji i konfiguracji nastąpi zmiana na drugi klasyczny interfejs
sieciowy. Logiczne definicje I/O przy braku systemu operacyjnego wykonywane są
na konsoli sprzętowej poprzez edycję
zbioru tekstowego do złudzenia przypominającego program asemblerowy zSeries
– i nie jest to przypadek. Opisanie partycji, przyporządkowanie wybranych adresów logicznych – ważne dla systemu zVM.
Potem uruchomienie procesu asemblacji
(tak – nie ma pomyłki), ponowne wczytanie konfiguracji (system pierwotnie ocenia to na dwie godziny, potem miłosiernie
„schodzi” do 20 minut, ostatecznie trwa to
minut kilka). Możemy startować.
Przyspieszamy
Aby praca szła szybciej, decydujemy się
na zrównoleglenie – mamy wszak już
trzy partycje (i jedno DVD). Mainframe
to inteligentne zwierzątko, potrafi się
uczyć od innych. Z tej nauki wynika
obecny proces instalacji – na konsoli
technicznej znajduje się napęd DVD,
w mikrokod został wbudowany proces
startu systemu z tegoż napędu. Jeśli na
płycie występuje odpowiednio spreparowana struktura katalogów i format zbiorów – nastąpi wczytanie jądra do pamięci. Wykorzystujemy ten mechanizm do
instalacji zVM. Chwila oczekiwania i na
tej samej konsoli technicznej w oknie
emulatora terminala pojawiają się
pierwsze komunikaty instalacyjnej wer-
sji zVM (wydanie 5.1). Specjalista od
„światów wirtualnych” zaczyna swoją
pracę. Niestety, oznacza to zajęcie napędu DVD na dłuższy czas.
Brać linuksowa niecierpliwie kręci się
na krzesłach – mamy co prawda do dyspozycji płytkę CD z Debianem, ale
gdzie ją umieścić? Na szczęście oprócz
płyty jako źródło jądra można podać adres serwera ftp. Trzeba jedynie umieścić
tam cztery zbiory: binarny obraz jądra,
binarny obraz ramdysku, zawartość pliku parametrów dla jądra i zbiór z rozszerzeniem ins, spinający to wszystko
w jedną całość (czyli, gdzie co rozmieścić w pamięci). Serwer ftp to nie pro-
KNOW HOW
blem, pozostaje jedynie wpiąć konsolę
techniczną do segmentu sieci, nadać jej
odpowiedni adres i ustawić trasowanie –
banalne, nawet w systemie OS/2.
Po chwili rozpoczynamy proces ładowania Linuksa – pierwsze komunikaty
pojawiają się na konsoli technicznej –
tym razem w trybie wierszowym. Nie jest
to pierwsza instalacja Debiana na tej platformie – przezornie przy konfiguracji pamiętaliśmy, że w tej wersji dystrybucji nie
ma obsługi karty sieciowej w tzw. trybie
kolejkowania (QDIO), a jedynie w trybie
kanałowym (tzw. emulacja LCS). Kilka
pytań o interfejs sieciowy, informacja
o widocznych dyskach (są wszystkie
VTOC - opis struktury dysku mainframe
Każdy format systemu plików zawiera „mapę” opisującą zawartość bloków dysku
i przyporządkowanie do określonych zbiorów. W przypadku zSeries w najpopularniejszym systemie
zOS informacje takie zawiera VTOC („Volume Table Of Contents”) złożony ze 140 bajtowych
struktur o nazwie DSCB („Data Set Control Block”). Każda z nich zawiera w pierwszej części 44
bajty przeznaczone na nazwę zbioru (kodowaną w standardzie EBCDIC, a nie w ASCII!), zaś
w drugiej dodatkowe informacje określające (w zależności od typu DSCB) – obszary zajęte przez
zbiór i jego cechy, obszary wolne lub dysk jako całość. Ponadto, zawsze w trzecim bloku
w pierwszej ścieżce pierwszego cylindra znajduje się etykieta dysku (sześć znaków w kodzie
EBCDIC) i adres VTOC (numer cylindra, ścieżki i bloku). Nazwa każdego zbioru składa się
z maksimum ośmioznakowych pól rozdzielonych kropkami i nie może przekraczać 44 bajtów
(pierwszy fragment DSCB). W ten sposób para: nazwa zbioru i etykieta dysku tworzą unikalnaą
identyfikację zbioru danych w systemie zOS. Aby zachować spójność danych i móc współużywać
narzędzi i procedur do kopii zapasowych z systemu z/OS – format dysków Linux wpisuje się
w obowiązujący schemat. Każda z trzech partycji jest reprezentowana w VTOC jako jeden zbiór.
Zabezpiecza to również przed nieumyślnym sformatowaniem dysków Linux z innej partycji.
WWW.LINUX-MAGAZINE.PL
NUMER 15 KWIECIEŃ 2005
69
KNOW HOW
Linux na mainframe
REXX - język skryptów
dla mainframe
Bez wątpienia można uznać, że każdy system operacyjny ma swoją filozofię i konsekwentnie stosuje ją w każdym obszarze. Dla
systemów Unix powszechnym jest stosowanie języka powłoki do automatyzacji zadań.
Perl, Awk, Sed i inne języki także posługują
się pojęciami Unix. W systemach Windows
taką rolę od kilku lat pełni Visual Basic (po
wieloletnim panowaniu zbiorów z rozszerzeniem bat). W systemach zSeries analogiczne zastosowanie ma REXX („Restructured
Extended Executor Language”), stworzony
w laboratoriach IBM w roku 1979. Składnię
i zasady odziedziczył po dwóch rodzicach -kompilowanym PL/I (inne dziecko IBM) i
EXEC2 (w swej ideologii przypominający
zbiory *.bat z DOS-a). Pierwsza implementacja dla VM/370 rozpowszechniana wewnątrz struktur IBM, szybko udowodniła
przydatność interpretowanego języka także
dla zewnętrznych użytkowników. Cechą
charakterystyczną REXX-a jest integracja
ze środowiskiem, w którym działa – frazy,
nie rozpoznane jako zmienne lub słowa kluczowe, zostają potraktowane jako polecenia zewnętrzne i wykonane przez otoczenie.
Dodatkowe mechanizmy przechwytujące
rezultaty wykonanej komendy i duże możliwości obróbki danych znakowych nadają
mu cechy „kleju” łączącego różne wywoływane narzędzia binarne. REXX doczekał
się wielu implementacji poza IBM, także
w świecie GNU, dla wszystkich znaczących
systemów operacyjnych. Dla tych, którzy
chcieliby poznać króla, dobra rada – niech
zaczną od królowej – popularny interpreter
REXX na licencji GNU nosi nazwę Regina.
wcześniej zdefiniowane) i próba pinga do
domyślnej bramy – odpowiada. Teraz
kontakt zewnętrzny -- w procesie inicjowania systemu został uruchomiony demon ssh – połączenie przez klienta udane. Rozpoczyna się proces instalacji.
W zasadzie logicznie jest to ten sam
proces, co na PC. Istnieją dyski, które należy sformatować (proces polega na zapisie bloków o stałej długości – w zSeries
możliwe są zapisy na dysku bloków
o zmiennej długości) – w wersji wierszowej wykonuje to program dasdfmt. Ze
względu na możliwe współistnienie innych systemów operacyjnych, które mogą również mieć dostęp do naszych dysków – struktura logiczna odzwierciedla
klasyczny format rozumiany przez z/OS
(zob. VTOC), gwarantując w ten sposób
widoczność takiego dysku z innych partycji jako sformatowanego (ponowny format wymaga specjalnych zabiegów). Na
tak spreparowanym nośniku znajdują się
maksimum trzy partycje (jest to podyktowane określonym przydziałem numerów urządzeń w Linux/ 390) – z perspektywy z/OS traktowane jako tzw. zbiory
sekwencyjne. Taka konstrukcja umożliwia przeprowadzenie procesu backup
z poziomu narzędzi z/OS lub z/VM. Do
partycjonowania w trybie wierszowym
jest używane polecenie... fdasd. Następnym etapem jest oczywiście inicjacja systemu plików – dla bezpieczeństwa stary
sprawdzony ext2 – w przeciwieństwie do
kilku innych, on zawsze powinien być
wkompilowany w jądro. Tak naprawdę
cały ten proces przeprowadza instalator
Debiana, ale brać linuksowa chętnie słucha, co się dzieje pod „kapturem”. Administrator Linuksa podejmuje decyzję minimalnej konfiguracji, więc proces przebiega szybko. Po chwili wszyscy z zapar-
tym tchem obserwują ponowny start pingwinka – tym razem już z dysków. Próba
logowania i… jest – mamy pierwszego
niebieskiego pingwina w Poznaniu.
Zespół nie spoczywa jednak na laurach
– wciąż pracujemy na tymczasowej konfiguracji – czas zmienić kartę sieciową na
tryb QDIO, ale jest to osiągalne jedynie
przez kompilację nowego jądra. Następna decyzja – próba odbędzie się na wersji
2.6.8 – do tej pory pracowaliśmy na 2.4.
Niestety, w podstawowej wersji dystrybucyjnej nie ma jeszcze możliwości wybierania wersji jądra z menu – najrozsądniej
stworzyć kopię dysku, na którym umieścimy nowo skompilowane jądro. W tym
momencie przychodzi nam z pomocą...
zVM, którego podstawowa instalacja właśnie się przed momentem zakończyła.
Aby jednak skorzystać z dobrodziejstw
tak wspaniałego narzędzia, trzeba mieć
do niego drogę dostępu.
Terminale, TCP/IP
i cała reszta
System z/VM współpracuje z kilkoma
różnymi terminalami – poczynając od
trybu wierszowego (dumb), na pełnoekranowym kończąc (rodzina 3270). Niestety,
ten ostatni nijak się ma do znanych z maszyn uniksowych wariantów i klonów VT
i tym podobnych. Wymyślony dla systemów transakcyjnych, realizuje filozofię
podziału ekranu na pola (rekordy) dla
wprowadzania i wyprowadzania informacji. Transmisja między rzeczywistym
komputerem a terminalem następuje jedynie po naciśnięciu specyficznych klawiszy (Enter, klawisze funkcyjne PF i PA,
reset i kilka innych). Ponadto, w typowej
konfiguracji przesyłane są jedynie informacje o polach, które uległy zmianie
(edytor vi nie byłby zadowolony).
OSA GbE 3270 - emulacja terminali w pudełku
Dziś prawdziwych nowych terminali już nie ma
– chciałoby się rzec -- i w przypadku 3270 jest
to prawda. Poza wciąż sprawnymi, choć z lekka przykurzonymi urządzeniami, pozostała
jednak filozofia obsługi, protokół TN3270
i emulatory. TN3270 to sposób transmisji kodów sterujących terminali 3270 przez kanał
TCP/IP wewnątrz protokołu Telnet (doczekał
się nawet kilku RFC). Jednakże dla systemu
operacyjnego takiego jak z/VM bądź z/OS pier-
70
NUMER 15 KWIECIEŃ 2005
wotna instalacja (a w niektórych ośrodkach
także docelowa – eh to bezpieczeństwo), nie
przewiduje działania stosu TCP/ IP. Aby ułatwić (a właściwie umożliwić) pracę w takich
przypadkach, IBM opracował tryb działania
karty OSA GbE (Gigabit Ethernet w wersji ze
skrętką), emulujący podłączenie rzeczywistych
urządzeń kanałowych. Ze strony użytkownika
wymagane jest podłączenie programu rozumiejącego TN3270, zaś konfiguracja systemu
WWW.LINUX-MAGAZINE.PL
operacyjnego zawiera opisy terminali podłączonych przez kanał wejścia/ wyjścia. Konfiguracja adresu IP, parametrów sesji, elementów
związanych z bezpieczeństwem (SSL) wykonywana jest z poziomu konsoli sprzętowej. Tak
sparametryzowana karta OSA nie ma możliwości pracy jako klasyczna karta sieciowa (dla
TCP/ IP w Linux lub z/VM), może za to obsłużyć jednocześnie kilka partycji na różnych sesjach (jest współdzielona).
Linux na mainframe
Z drugiej strony, jak często mamy
dziś do czynienia z rzeczywistym terminalem? Powszechnie używana sieć
i protokół TCP/ IP (ssh i telnet) to standard. Jak wobec tego dostać się do zVM,
aby w pełni wykorzystać jego możliwości? Na szczęście, Internet pełen jest
wspaniałych, darmowych rozwiązań –
i takie też istnieje dla naszego problemu. Nazywa się x3270 (lub szerzej
x3270suite) i jest dobrą realizacją protokołu TN3270 – czyli emuluje terminal 3270 obsługiwany przez protokół
telnet. zVM wspiera takie rozwiązanie
od wielu lat i doskonale współpracuje
z x3270. Aby zabezpieczyć się przed
niespodziankami, wykorzystujemy jeszcze jedno rozwiązanie – emulację terminali w karcie OSA GbE (zob. ramka).
Jak tak dalej pójdzie – zabraknie nam
adresów IP w dedykowanej podsieci
(4 karty * 3 partycje to już 12 adresów).
Pozostaje wobec tego jedna mała drobnostka – skonfigurować TCP/ IP w zVM.
Na szczęście, na etapie instalacji istnieje
skrypt automatycznie wstawiający parametry konfiguracyjne dla opisanych interfejsów sieciowych. Jest to swoiste błogosławieństwo dla początkującego vm-owca,
gdyż przy całej swej przyjacielskości jest
to nadal środowisko mainframe. Przystępujemy więc do uruchomienia zVM zainstalowanego na dyskach (poprzedni start
odbył się z DVD) – po komunikatach na
konsoli o zakończeniu procesu startu
i uruchomieniu TCP/ IP (w zVM jest to
osobna usługa) – pierwszy test to, oczywiście, ping – DZIAŁA! Próba logowania
świeżo skompilowanym x3270 – jest pytanie o login i hasło – weszliśmy.
Maszyna wirtualna zamiast
partycji
Dlaczego zVM ma nam pomóc w kompilacji jądra? Poprzez prostą edycję zbiorów konfiguracyjnych istnieje możliwość zdefiniowania wirtualnego komputera z urządzeniami, których nie ma
lub są w zupełnie innym miejscu (czyli
mają inne adresy). Ponadto zamiast
udostępniać cały dysk (a więc o.. 3 GB),
można zdefiniować tzw. minidysk (określony przedział cylindrów przez maszynę wirtualną traktowany jako dysk rzeczywisty, tylko mniejszy). Ponadto Debian w swej pierwotnej dystrybucji udostępnia obsługę tzw. połączenia CTC
(Channel To Channel connection), któ-
KNOW HOW
Rysunek 1: Przykład elastyczności połączeń w z/VM – w takiej konfiguracji możemy testować
różne warianty.
re zVM perfekcyjnie emuluje – konfiguracja, w której mamy dwa interfejsy sieciowe – stabilny (CTC) i testowany
(OSA QDIO) jest – idealna dla naszych
potrzeb. Zamykamy więc pierwotną instancję Linuksa – traktowaną jako referencyjna, szybka kopia fizyczna dysku
narzędziem zVM DDR (Disk Dump
Restore) i ponowny start Debiana – tym
razem już pod kontrolą zVM. Rolę konsoli sprzętowej przejmuje terminal maszyny wirtualnej. Polecenia zVM dynamicznie definiują wirtualne urządzenie
CTC, moduł jądra 2.4 ctc. o zapewnia
obsługę od strony Linuksa, konfiguracja
CTC TCP/ VM zapewnia obsługę z drugiej strony. Typ połączenia pointopoint,
jeszcze tylko odpowiedni opis tras i... logujemy się do Linuksa przez zVM jako
ruter.
Kompilacja jądra
Każdy kiedyś musi skompilować jądro,
ale przesiadka z wersji 2.4 na wersję
2.6 to „jazda bez trzymanki”. Jeśli do te-
WWW.LINUX-MAGAZINE.PL
go decydujemy się na zmianę trybu z 32
bitów na 64 przy nie zmienionych aplikacjach – to mogą być tylko kłopoty.
I są – ale w zupełnie innym miejscu.
Debian w wersji 2.4 w dystrybucji
S/390 wykorzystuje koncepcję devfs
(zarzuconą w jądrze 2.6). Oznacza to, ni
mniej ni więcej, obecność takich podkatalogów w /dev jak:
/dev/dasd/0250
/dev/dasd/0250/disc
/dev/dasd/0250/part1
/dev/dasd/0250/device
Po kompilacji (wariant 64 bity z opcją
obsługi programów i API 32-bitowego)
i zdefiniowaniu następnej maszyny wirtualnej następuje format i podział na
partycje minidysku, montowanie i kopia
niezbędnych plików (przy testach można
się przecież obejść bez /usr/*). Następnie
magiczne polecenie chroot (choćby po to,
by sprawdzić, czy uruchomi się bash)
i konfiguracja parametrów startowych
NUMER 15 KWIECIEŃ 2005
71
KNOW HOW
Linux na mainframe
(/etc/zipl. conf). Wywołanie zipl zapisze
nowe parametry startowe na urządzeniu,
na którym fizycznie (minidysk) znajduje
się plik konfiguracji. Wywołanie exit, odmontowanie minidysku i...
Maszyna z jądrem 2.6
Jak powstaje nowa maszyna – po prostu
trzeba się zalogować jako nowy użytkownik: np.: DEBIAN2. Podczas procesu logowania odczytywana jest charakterystyka wirtualnego komputera – ilość pamięci, ilość procesorów (do 32 – ale lepiej nie
eksperymentować, jeśli ma się rzeczywiście tylko 2), konfiguracja minidysków
i innych urządzeń. Jeśli w opisie znajduje
się też zdanie IPL xxxx (xxxx – to adres
urządzenia wirtualnego) – to nastąpi próba automatycznego startu systemu z tego
urządzenia). Jeśli nie – mamy dostęp do
tzw. procesora kontrolnego (CP), w którym oprócz ręcznego startu możemy
zmienić dodatkowo inne parametry (specjalną sytuacją jest uruchomienie systemu CMS, w którym następuje np. edycja
zbiorów lub wykonanie skryptów w języku REXX. Finalnym poleceniem takiego
skryptu może być IPL xxxx). My pozwoliliśmy sobie na pełną kontrolę i po zalogowaniu ręcznie uruchomiamy proces star-
tu, podając adres przed chwilą spreparowanego minidysku. Efekt – panika – brak
/dev/console. Winowajca – devfs, proces
poprawy – montowanie minidysku w drugiej maszynie (z Linux 2.4), dodanie wpisów, ponowny start – i tak kilka razy.
A kiedy już wydaje się, że wszystko gra –
brak paniki – znów trzeba walczyć z interfejsem sieciowym. Ale tu niespodziankę
sprawia już sam Linux – a raczej jego elastycznosć.
prezentujący fizyczne urządzenia podłączone do systemu. Skorzystali z tego
dobrodziejstwa także autorzy implementacji Linuksa na zSeries – w wersji
2.6 każdy kanał i urządzenie ma swoje
odzwierciedlenie w sysfs. Komplikuje
to proces konfiguracji np. interfejsów
sieciowych, ale daje gwarancję „trafienia” z adresem IP w odpowiednią „szczelinę”. Plug’n’play w mainframe – to fakt,
dzięki zVM i sysfs.
Dynamika w każdym calu
Koniec?
Nie, to dopiero początek...
W czym dzisiejszy PC przypomina zVM
– w łatwości dodania nowego urządzenia podczas pracy. Tak jak w zVM można zdefiniować i dołączyć nowy dysk do
maszyny wirtualnej, tak samo równie
łatwo podłączyć do PC przez USB nowy
FlashDisk lub inne urządzenie. Zauważyli to główni architekci nowego jądra,
obserwując jednocześnie, jak trudno
poradzić sobie z odpowiedzią na pytanie, jaki numer węzła (lub nazwa pliku
albo nazwa urządzenia sieciowego) reprezentuje rzeczywiste urządzenie fizyczne. Wszak kolejność podłączania
determinuje dynamiczny przydział i
węzłów. Odpowiedzią na to jest nowy
system plików sysfs, dynamicznie re-
Cały proces podnoszenia pingwiniarni
trwał trzy dni – dzięki doskonałej współpracy między mainframowcami i linuksowcami – to była wspaniała zabawa
i ciekawa – choć długotrwała – praca (ale
kto przy takich okazjach patrzy na zegarek?). Dalej następuje montaż maszyn
wirtualnych, Linuksów i stopniowe odkrywanie zVM przez brać linuksową. Pytania w stylu: „Jak dołożyć drugi procesor wirtualny?”, „Jak współdzielić dyski
między maszynami?”, „Jak skonfigurować NFS pod zVM?” to małe kroki do
odkrywania wspaniałego wirtualnego
świata – a możliwości jest dużo więcej.
Ale o tym w następnym artykule.
■
Łączenie maszyn wirtualnych
zVM udostępnia wiele mechanizmów łączenia maszyn wirtualnych. Na
Rysunku 1 zostały pokazane dwa skrajnie różne rozwiązania, które
z punktu widzenia jądra Linux są obsługiwane jak ich rzeczywiste (sprzętowe) odpowiedniki. Pierwsze, oznaczone jako CTC, reprezentuje połączenie typu punkt-punkt (bez zVM jest to kabel światłowodowy między
dwiema partycjami). Moduł w jądrze to ctc. o, konfiguracja analogiczna
do PPP (dwa adresy IP przyporządkowane do jednego interfejsu sieciowego). Takie rozwiązanie wymaga, by jedna z maszyn wirtualnych pełniła rolę rutera (jeśli potrzebne jest połączenie ze światem zewnętrznym).
Drugie rozwiązanie symuluje wirtualny przełącznik sieciowy (VLAN –
VSWITCH) w warstwie TCP/IP (a w niedługim czasie w warstwie Ethernet). Punktem styku jest tutaj wirtualna karta sieciowa (VNIC) – dla jądra
Linux widziana jako urządzenie QDIO (bez z/VM jest to klasyczna karta
OSA w trybie QDIO). Konfiguracja interfejsu sieciowego odbywa się na
takich samych zasadach jak innych kart Ethernet. Umożliwia to obsługę
na poziomie podsieci (opisywanej maską) oraz generowania pakietów
typu „broadcast”. Taka sieć wirtualna może być tworem zamkniętym
bądź (tak jak na rysunku) może zostać podłączona do stosu TCP/ IP
systemu z/VM, działającego w tym przypadku w trybie mostka sieciowego. Ponadto w pełni jest obsługiwany standard VLAN (dodawane są
identyfikatory sieci wirtualnych).
Pomiędzy tymi dwoma skrajnymi rozwiązaniami istnieje wiele pośrednich
– część opiera się na istnieniu rzeczywistych urządzeń sieciowych dedykowanych do konkretnej maszyny wirtualnej (np. OSA w trybie LCS), zaś
72
NUMER 15 KWIECIEŃ 2005
część działa jedynie pod z/VM (np. sieć wirtualna bez obsługi VLAN lub
połączenie punkt-punkt korzystające ze wspólnej pamięci w obszarze
programu sterującego CP – określana akronimem IUCV – „Inter-User
Communication Vehicle”).
Sterowanie połączeniami, sprzęganie maszyn wirtualnych, generacja dynamiczna urządzeń wirtualnych (VSWITCh, VNIC, VLAN, CTC) odbywa się
z poziomu programu zarządzającego (CP – Control Program) i standardowo
jest wykonywana z sesji 3270 maszyny zarządzanej – odpowiada to funkcjonalnie konsoli sprzętowej w osobnym procesorze. Ze względu na pełną dynamikę generacji i kasowania urządzeń wirtualnych, nieocenione usługi oddaje tu wirtulany system plików sysfs zaimplementowany w jądrze 2.6.
Osobną pozycją na rysunku jest CMS – interaktywny system operacyjny działający jedynie w maszynie wirtualnej (bo wspierany przez dodatkowe usługi
CP, których brak w mikrokodzie). Filozofia jego działania opiera się na komunikacji z użytkownikiem poprzez terminal 3270, generowany w maszynie
wirtualnej jako urządzenie kanałowe, stąd wynika brak jakichkolwiek połączeń sieciowych ze światem zewnętrznym. Jednocześnie maszyna wirtualna
TCP/ IP systemu z/VM zapewnia transmisję (poprzez wewnętrzne mechanizmy CP) strumienia danych wirtualnego terminala do stacji roboczej z emulatorem 3270. CMS zawiera w sobie m.in. interpreter języka REXX (zob.
ramka), rozbudowany edytor pełnoekranowy XEDIT (w którym administrator systemu z/VM spędza znaczną ilość czasu) i umożliwia sprzężenie z innymi usługami (formatowanie minidysku, polecenia diagnostyczne PING,
NETSTAT, generacja i konfiguracja maszyn wirtualnych itp.).
WWW.LINUX-MAGAZINE.PL