Zmiana definicji oprogramowania skalowalnego dla zaawansowanych struktur sieciowych

Transkrypt

1 Po to, aby stworzyć produkty o szerokim zastosowaniu sieciowym, wytwórcy sprzętu inwestują jednocześnie w wiele systemów operacyjnych. Skutki są łatwe do przewidzenia: kody źródłowe tych produktów nie są przenaszalne pomiędzy wyrobami, informatycy nie są w stanie bezproblemowo wdrażać się w projekty na różnych platformach systemowych. Produkty wykorzystujące sieć wciąż nie oferują pełnej zgodności obsługi programowej i narzędzi koniecznych do efektywnego zarządzania. Dotyka to także użytkowników, którzy szybko spotykają się z tymi niedogodnościami. Odcinanie się od rozwiązań odpowiadających wymaganiom dostępności i skalowalności czyli takich sprawdzających się przy liniowo rosnących problemach (w obliczeniach, przechowywaniu informacji, a także w rozpatrywanym temacie - sieciach), w ostateczności prowadzi do nikąd. Poniżej przyjrzymy się, jak mikrojądro systemu operacyjnego oparte o przeźroczystą sieć IPC (Interprocess Communication) obsługuje poszczególne urządzenia na trochę innym poziomie niż tradycyjne jądra systemów operacyjnych. Przy takiej architekturze, te same aplikacje mogą działać w systemach jednoprocesorowych, bądź też w inny sposób - pomiędzy rozproszonymi procesorami lub też pracować w systemach serwerowych SMP (Symmetric Multi-Processing). Nie ma przy tym potrzeby ponownego przekodowywania i linkowania. Co do efektu - to nie trzeba chyba nikogo przekonywać. Mniej skomplikowane oprogramowanie, spójność produktów i wyższe zyski po stronie producenta i co najważniejsze - oszczędności użytkownika. Koszty i jeszcze raz koszty Firmy zajmujące się przenaszalnymi sieciowymi urządzeniami (carrier-class equipment) z pewnością docenią możliwość powtórnego użycia oprogramowania dla całego asortymentu produktów. Procentuje to bowiem dużymi zyskami komercyjnymi. Idzie za tym szybsze projektowanie oraz krótszy proces produkcji i wydania produktu na rynek. Dotychczas bowiem programiści, w swoich wysiłkach w budowaniu rozproszonych sieci zakrojonych na szeroką skalę, opierali się na różnych platformach systemowych. Producenci zaś z konieczności zainwestowali w kilka lub kilkanaście systemów operacyjnych, a każdy z nich wyposażony jest w inne narzędzia i inne API (Application Programming Interface). Skutki są łatwe do przewidzenia. Raczej częściej niż rzadziej kody nie mogą być użyte w projektach realizowanych na maszynach działających z różnymi systemami. Programiści muszą przejść fazę nauki nowych systemów i nowych narzędzi, jeżeli chcą podjąć się próby zapoznania się z projektami swoich kolegów. Widać więc wyraźnie, że uniwersalność oprogramowania jest znacznie ograniczona i zawężona do jednej, dwóch platform. Użytkowników może przyprawić o zawrót głowy to, że jak różne są programy, tak różne są ich interfejsy i narzędzia obsługi. Gdy klient przyswoi sobie umiejętności obsługi jednego, wcale nie daje mu to gwarancji, że będzie potrafił użyć innego. Pociąga to za sobą wyższe koszty posiadania odpowiedniego oprogramowania i szkolenia personelu. Skalowalność to konieczność A co by było, gdyby te wszystkie systemy operacyjne nie były potrzebne? Najlepsza byłaby sytuacja, gdyby jeden OS pozwalał na użycie tego samego kodu, narzędzi i interfejsu programowego. Zadanie wydaje się być trudne. Co więcej taki system powinien posiadać wbudowane mechanizmy ogromnej skalowalności. Na przykład: adresować różne konfiguracje pamięci od setek kilobajtów do gigabajtów sterować setkami, a nawet tysiącami jednoczesnych procesów programowych (by zapewnić gotowość systemową, OS powinien wirtualnie wykonywać te procesy) pozwalać tym samym aplikacjom i sterownikom wykonywać się na jednostkach z jednym procesorem, poprzez sieć słabo powiązanych procesorów lub przez klastry SMP bez żadnego przekodowywania. Skalowalność i luźno powiązane procesory Tradycyjna architektura systemu operacyjnego zawodzi na wszystkich wymienionych wyżej polach szczególnie na ostatnim. Rozpatrzmy taką sytuację: W rozproszonej architekturze współczesnych serwerów najwyższej klasy (high end), rozrost sieci, teoretycznie jest łatwy do przeprowadzenia po prostu zwiększa się liczbę kart sieciowych, a każda z nich podejmuje swój routing (sama szuka odpowiedniej ścieżki do zdalnego serwera). Z jednej strony decentralizacja likwiduje wąskie gardło, jakie tworzy pojedynczy procesor obsługujący routing. Z drugiej jednak, wiele kart liniowych (line cards) usiłujących naraz komunikować się z głównym procesorem szybko obciąży szynę systemową. W rezultacie router nie może przyjąć zwiększonego ruchu nawet jeśli ma wystarczająco dużo mocy przetwarzania. Rozwiązanie jakie się rysuje, to inteligentne oprogramowanie, takie jak np. rozproszona baza danych, umieszczona z dala od głównego procesora, komunikująca się przez karty liniowe, które zwalniają z tego obowiązku nie przystosowaną to takich zastosowań szynę systemową. 1

2 Niestety, tradycyjne architektury systemów operacyjnych stwarzają problemy przy przenoszeniu baz danych z kilku powodów. Po pierwsze, większość systemów operacyjnych nie umożliwia przeźroczystej, międzyprocesowej komunikacji. Tak więc, jeśli rozdzieli się wykonywanie aplikacji pomiędzy różne procesory, trzeba uwzględnić specjalny kod sieciowy, by te części aplikacji mogły rozmawiać ze sobą. W naszym wypadku trzeba przekodować bazę danych, łącznie z całym oprogramowaniem, z którym się komunikuje. Wszystkie, lub prawie wszystkie moduły programów w systemach czasu rzeczywistego związane są z jądrem. Okazuje się, żeby przenieść proces związany z obsługą bazy danych z procesora do karty linii, prawdopodobnie nie obejdzie się bez stworzenia dwóch obrazów jądra systemu jednego dla karty linii, a drugiego dla głównej jednostki CPU. Oczywiście podobne problemy wystąpią, jeżeli następować będą próby przeniesienia operacji wykonywanych przez kilka procesorów na poziom niższy tzn. na oprogramowanie dotyczące obsługi tylko jednego procesora. Tak czy owak, aplikacja będzie ograniczona przez oprogramowanie. Dzięki przeźroczystości komunikacji sieciowej IPC, każdy proces może być przenoszony między procesorami, bez potrzeby przekodowywania. Dotyczy to także wszystkich procesów, z którymi się komunikuje. Podobnie, różne procesy tworzące aplikację mogą działać zarówno na pojedynczym CPU lub być rozdysponowane pomiędzy grupę luźno powiązanych procesorów bez potrzeby przekodowywania. QNX to rozwiązanie? System czasu rzeczywistego QNX ma receptę na te dolegliwości. Po pierwsze używa rzeczywistego mikrojądra, by rozdzielić aplikacje, warstwy protokołów sieciowych, sterowniki i nawet wysokiego poziomu serwisy systemu (np. obsługę plików) od jądra OS-a. W rezultacie każdy moduł programowy może być samodzielnym, chronionym przez MMU (Memory Management Unit) procesem, którego kod może być przenoszony bez potrzeby przełączania, z jednego procesora na drugi. Nie jest przy tym wymagana rekonfiguracja jądra czy też jego ponowne testowanie. nie klient nie ma potrzeby wiedzieć, gdzie rezyduje zarządca bazy danych. Użytkownik wpisuje ścieżkę zakończoną nazwą pliku, a system operacyjny automa- tycznie zleca dany proces. Dzięki architekturze opartej o mikrojądro każdy sterownik, aplika- cja i warstwa protokołu działa jako osobny, chroniony przez MMU proces. programu, po prostu nie ma różnicy, czy wykorzystuje się zasoby lokalne, czy sieciowe. Ale tak naprawdę aplikacja będzie potrzebować specjalnego kodu, by stwierdzić, gdzie znajduje się obsługa zasobu powiedzmy bazy danych, pliku czy urządzenia I/O na lokalnym CPU czy na innym procesorze dostępnym poprzez sieć. W QNX ten kod jest przeniesiony do osobnego sterownika. Kontynuacja tego zaowocowała stworzeniem sieciowej przestrzeni adresowej. Oprócz przeźroczysto- ści sieci w przesyłaniu komunikatów system czasu rzeczywistego QNX omija ograniczenia sieci, zezwalając na korzystanie ze wszystkich jej zasobów poprzez jednolity system nazywania plików i urządzeń I/O. Na przykład, jeśli administrator bazy danych w powyższej Po drugie system czasu rzeczywistego QNX posiada globalny interfejs przesyłania komunikatów systemo- wych (message passing) - działa on identycznie zarówno podczas zadań lokalnych, jak i sieciowych. Każdy proces, czy też tylko wątek wykonywany na danym CPU, może przeźroczyście przenikać do zasobów związanych z innym procesorem. Nie jest wymagane do tego żadne kodowanie sieciowe. Co istotne, z poziomu sytuacji chce obsłużyć operacje przy pomocy innych serwisów, może określić własną ścieżkę w katalogu (przestrzeni adresowej). Każda aplikacja typu klient, która życzy sobie użycia danego serwisu wywołuje polecenia standardu POSIX open(), read(), write(), i tak dalej w tej ścieżce. Menadżer bazy danych podejmie odpowiednie działanie zgodne z wywołanymi przez tą aplikację poleceniami. W takich przypadkach nie jest ważne, który CPU obsługuje klienta. Analogicz- Jak QNX radzi sobie ze zleceniami Spójrzmy na inny aspekt obsługi ruchu na sieci przez wiele kart linii. Tym razem, zamiast przenoszenia baz danych możemy postąpić inaczej. Angażujemy dwa procesory, każdy z nich mirrorujący bazę danych i korzystamy z zarządcy dzielenia obciążenia (load-sharing manager), który zacznie przesyłać przychodzące zlecenia z kart linii do obydwu procesorów. 2

3 Poza obsługą wielu kart linii, takie rozwiązanie prowadzi do dublowania mocy obliczeniowej w wypadku, gdy główna jednostka CPU jest niesprawna nasz zarządca automatycznie przekierowuje wszystkie zgłoszenia do sprawnej bazy danych do czasu, aż awaria nie zostanie usunięta. Ważne jest, że istniejące aplikacje nie muszą być modyfikowane. Na przykład, jeśli proces na karcie linii zgłasza zapytanie do bazy danych, będzie używał tej samej ścieżki, niezależnie który procesor w rzeczywistości jest odpowiedzialny za ten proces. Zarządca równoważenia obciążeń (load-balancing manager) zdecyduje, do którego procesora nadejdzie żądanie, bez ingerencji aplikacji. większą przepustowość, ale i tolerancję na uszkodzenia oraz możliwość kontynuacji pracy pomimo ich wystąpienia. System ten charakteryzują mechanizmy: Równoważenie obciążeń Działa on na zasadzie kolejkowania pakietów na łączach. Skutkuje to szybszym ich przesyłaniem, opartym o bieżące obciążenie i pojemność łącza. Ta metoda używa kombinowanej obsługi wszystkich łącz, by wykorzystać do maksimum ich przepustowość. Pozwala zarazem systemowi na dynamiczną kontrolę przesyłania informacji, np. na zmniejszenie transferu, gdy łącze ulegnie uszkodzeniu. Gdy już do tego dojdzie, co jakiś czas wysyłane są na to łącze odpowiednie pakiety kontrolne, które mają za zadanie sprawdzić, czy przywrócono połączenie do stanu używalności. Łącza redundantne To przesyłanie każdego pakietu danych równolegle, przez wszystkie dostępne łącza jednocześnie. Jeśli pakiet na łączu A dotrze do celu szybciej niż ten sam pakiet na łączu B to pakiet przesyłany przez A wygrywa. Te same pakiety otrzymywane później są po prostu opuszczane. Dzięki temu rozwiązaniu serwer może kontynuować pracę bez zająknięcia, gdy którekolwiek z łącz przestanie nagle działać. Przeźroczystość sieci upraszcza budowę systemów redundantnych 2N. Programy nie wymagają wiedzy o tym, na ilu procesorach będą uruchamiane. Zlecenia przychodzące do bazy danych obsługuje zarządca dzielenia obciążenia. Prowadzi to do większej skalowalności i jasno zdefiniowanej, rozproszonej budowy. Skalowana przepustowość przez wiele połączeń sieciowych Dotychczas przyjrzeliśmy się kilku sytuacjom, w których przeźroczystość sieci może pomóc w obsłudze większego ruchu sieciowego i tym samym zwiększyć skalowalność. Czasem jedyne rozwiązanie to zwiększenie przepustowości. Na przykład możemy połączyć procesory przez kilka łącz możliwa staje się wtedy komunikacja poprzez matrycę przełączającą, szynę systemową, połączenie szeregowe lub dowolną ich kombinację. Zwykle bezproblemowa współpraca i obsługa wielu połączeń przez różne typy łącz nie jest domeną systemów operacyjnych. Powszechną praktyką jest, że przeźroczystość sieci jest implementowana ręcznie dla każdego protokołu to powoduje, że każda aplikacja jest uczulona na różne połączenia, korzystające z różnych protokołów. IPC nie spełnia więc w takim systemie swojej roli. W odróżnieniu, QNX dostarcza wbudowaną obsługę dla wielu łącz, bez potrzeby wdrażania specjalnego kodu aplikacyjnego. Ta cecha zapewnia nie tylko Sekwencyjność To przesyłanie wszystkich pakietów przez jedno łącze, aż do czasu awarii. Wtedy następuje rozpoczęcie transmisji przez drugie łącze (w razie potrzeby trzecie, czwarte, itd.). To rozwiązanie nie jest tak efektywne w sensie przepustowości, ale także zapewnia tolerancję uszkodzeń łączy. Co ważne, zarządca zasobów QNX-a Qnet, który zajmuje się tymi mechanizmami, nie ma nic wspólnego z protokołami transportowymi. Nie interesuje się, jakie łącza są używane. Także nie robią tego aplikacje użytkownika. Zajmuje się tym specjalny, osobny sterownik, który komunikuje się bezpośrednio ze sprzętem. Takie rozwiązanie zapewnia: Swobodę dopasowywania interfejsów Dzięki temu projektanci mogą swobodnie operować łączami sieciowymi. Jednym łączem może być światłowód, drugim łącze szeregowe itd. Nie potrzebują one programu kodującego. To samo odnosi się do łączenia procesorów pracujących na różnych maszynach. Można swobodnie korzystać z ATM, ISDN, 100Mb/sec Ethernet, itd. Lepsze wykorzystanie istniejących kodów Od czasu, gdy aplikacje nie muszą już zajmować się tym, ile łączy, jakie rodzaje i czy w ogóle jakieś łącza są potrzebne pomiędzy procesorami możliwe stanie się przenoszenie ich kodów źródłowych, ich ponowne użycie i konfiguracja w całym asortymencie produktów danej grupy. 3

4 Przykładowo aplikacja bazy danych może komunikować się z klientami działającymi na innej szynie. Przy innej instalacji, ten sam program może działać na zupełnie innej maszynie połączonej z centralą kilkoma łączami Ethernet. W jeszcze innym przypadku, baza i klient mogą pracować na tym samym procesorze. W żadnej z tych sytuacji baza i klient nie widzą różnicy. Takie podejście daje również swobodę w projektowaniu nowych architektur sieciowych. Skalowalność w wieloprocesorowych SMP W wielu urządzeniach sieciowych obciążenie związane z obsługą kontroli realizowane dotychczas przez CPU rozrosło się do punktu, gdzie nawet najszybsze procesory mają problemy, by sprostać temu zadaniu. Na przykład w routerze klasy high-end, CPU musi obsługiwać złożone obliczeniowo protokoły, takie jak OSPF, utrzymywać routing bazy danych o lub więcej wpisach, obsługiwać funkcje OA&M, zarządzać pakietami procesowymi SNMP. Oprócz tego musi obsłużyć każde nowe zlecenie przychodzące przez łącze. Przy przepustowości sieci dwukrotnie większej niż szybkość przetwarzania CPU rozwiązanie nie wydaje się oczywiste. By sprostać tym wymaganiom obliczeniowym, coraz więcej projektantów systemów stara się rozłożyć pracę na wiele jednostek CPU używając rozwiązań SMP. System czasu rzeczywistego QNX jest zgodny ze specyfikacją Intel MultiProcessor Specification i może obsłużyć do ośmiu procesorów Pentium lub Pentium Pro. Jest jeszcze następne zagadnienie. Podczas, gdy SMP może widocznie zwiększyć wydajność to jednak zyski z takiego rozwiązania mogą być zaprzepaszczone z powodów kosztów utrzymania i zarządzania (np. problem rywalizacji procesorów o przydział tego samego zbioru pamięci). Jest ważne więc, by system operacyjny zainstalowany na SMP był na to przygotowany i nie stwarzał niepotrzebnych kosztów związanych z jego działalnością. Jądro dużych systemów operacyjnych to zwykle tysiące linijek kodu, tak więc dodanie do niego obsługi SMP wymaga wielu pracochłonnych modyfikacji i ingerencji w jego kod. Także wszystkie sterowniki urządzeń działają w przestrzeni jądra - zaimplementowanie obsługi SMP oznacza także zmiany w każdym z nich. To może zniechęcać do przejścia na SMP stwarza bowiem niemałą trudność zaimplementowanie obsługi wieloprocesorowości w oprogramowaniu. W konsekwencji programiści są zmuszeni często wdrażać okrojone aplikacje, w których tylko niektóre procesy mogą być uruchamiane na drugim procesorze w rezultacie wykorzystując tylko około 10-30% jego mocy obliczeniowej. Przekodowywanie przez mikrojądro System operacyjny oparty o architekturę mikrojądra, jakim jest np. QNX RTOS nie styka się z takimi problemami. W porównaniu do obszernych jąder najpopularniejszych OS-ów, mikrojądro QNX-a jest zadziwiająco małe. Wynika to z tego, iż większość programów obsługi zwykle znajdujących się w jądrze (system plików, sterowniki, warstwy protokołów, itd.) w QNX istnieje jako programy użytkowe wywoływane poza przestrzenią jądra. Co za tym idzie, modyfikacje jądra na potrzeby SMP są niewielkie po prostu kilka dodatkowych kilobajtów kodu. Wyłącznie ta zmiana jest konieczna. Wszystkie inne wielowątkowe procesy system plików, sterowniki, aplikacje mogą korzystać z dobrodziejstw SMP bez potrzeby zmian ich kodów. SMP charakteryzuje się przetwarzaniem współbieżnym na kilku procesorach, współdzieleniem pamięci i urządzeń I/O oraz systemu operacyjnego. Zaletą SMP jest docelowe znaczące obniżenie kosztów. Koncepcja ta daje możliwość rozbudowy i zwiększenia mocy obliczeniowej przez rozszerzenie istniejącego systemu o dodatkowe moduły procesorowe. Przed wyborem systemu operacyjnego działającego w jednostce typu SMP użytkownicy powinni uważnie rozpatrzyć kwestię tego, czy przy danym OS-ie rozwiązania programowe dotyczące przenaszalności kodów źródłowych rodziny programów nadają się do zastosowania zarówno w środowiskach jedno- i wielo- procesorowych. Podjęcie takiego kroku zapewni większe zyski, kompletną zgodność oprogramowania w całej serii produktów i zwiększoną niezawodność. Dzięki architekturze mikrojądra sterowniki, warstwy protokołów, moduły systemu operacyjnego mogą być przenoszone z jednostek jednoprocesorowych na systemy SMP, bądź też rozproszone w sieci luźno powiązanych jednostek SMP - bez potrzeby ich przekodowywania. 4

5 Działanie SMP w czasie rzeczywistym By zapewnić optymalną wydajność pamięci podręcznej (cache) procesora, system czasu rzeczywistego QNX obsługuje jądro w taki sposób, że zawsze dąży do tego, by dostarczyć wątek do CPU, który go ostatnio obsługi- zwiększenia wydajności może ona przekierować wszystkie nie wymagające czasu rzeczywistego wątki do wał. QNX dostarcza także tzw. affinity mask do dalszego danego procesora. Pozostałe procesory będą więc miały do spełnienia inne zadanie - przyjęcie na siebie ciężaru wykonywania krytycznych zdarzeń. QNX realtime sche- duler działa w ten sposób, że zawsze dąży do obsłużenia procesów o niższym priorytecie, zaraz potem, gdy te ważniejsze są już gotowe. Dzięki tej wstępnej selekcji QNX RTOS może pomóc SMP w obsłudze przeciążonego systemu, bez kosztów zakupu dodatkowych procesorów. Krytyczne zadania są zawsze wykonywane w ustalonej jednostce czasu, niezależnie od tego, ile procesów wymaga czasu procesora. Czasy odpowiedzi pozostają stałe, nawet przy zwiększeniu obciążenia całego systemu. QNX oferuje także przełączanie kon- tekstów (wątków i procesów) w czasie mniejszym niż mikrosekunda. Efekt? - CPU traci mniej czasu na przełączanie z jednego wątku na drugi i ma więcej efektyw- właśnie prawdziwa nego czasu na wykonanie złożonych aplikacji. To jest skalowalność. Co na tym zyskamy? Jak widzieliśmy, nie wystarczy, by system operacyjny skalował w dół lub w górę zasoby pamięci lub obsługiwał SMP. Musi gwarantować produktom programowym współpracę z całą gamą produktów sieciowych od urządzeń znakowych do gigabitowych routerów bez przeprojektowywania, przekodowywania i ponownego testowania działania. Dając szeroki asortyment produktów sieciowych, produ- wynikające z kosztów programowania i szybkości wy- cenci mogą otrzymać wymierne komercyjne korzyści puszczania na rynek kolejnych produktów. Z omawianymi rozwiązaniami systemu QNX na poziomie mikroją- ponownie dra nie ma potrzeby, by przekodowywać i linkować programy, pod warunkiem, że oprogramowanie ma oznaczenie SMP safe i jest dostosowane do takich rozwiązań. Satysfakcja klientów, którzy z pewnością docenią wygodę i zauważą poczynione oszczędności z racji niższych kosztów zakupu. Wreszcie będą mieli spójny zestawu narzędzi i interfejsów na przestrzeni całego systemu komputerowego. Na podstawie: Redefining Software Scalability for the Network Infrastructure Paul N.Leroux Firma QNX Software Systems ma mocną pozycję na światowym rynku IT. Jej produkt - QNX Neutrino RTOS - plasuje się na pierwszym miejscu najbardziej niezawodnych i najczęściej stosowanych systemów czasu rzeczywistego na potrzeby przemysłu. Jest stworzony do zastosowań sieciowych, na potrzeby motoryzacji, inteligentnych urządzeń lub zastosowań krytycznych. Używają go najbardziej renomowani producenci na całym świecie, jak: Cisco, Delphi, Siemens, Alcatel, Sony, Texaco czy Ford. Oni już zaufali technologii QNX na potrzeby obsługi routerów sieciowych, systemów medycznych, inteligentnego transportu danych. QNX jest stosowany w systemach bezpieczeństwa i ochrony. Ma szansę być wdrożonym do następnej generacji robotów. QNX istnieje już na rynku przemysłowym od ponad dwudziestu lat. Jest sprzedawany i cieszy się uznaniem w ponad stu krajach na całym świecie. Kontakt QSSL North America Fax France info@qnx.com Germany. +49 (0) Support... support.qnx.com Japan +81 (0) Northern Europe United Kingdom +44 (0) w ww.qnx.com 2002, QNX Software Systems Ltd. QNX is a registered trademark, of QNX Software Systems Ltd. All other trademarks belong to their respective owners. Dystrybutor QTTC QUANTUM Korporacja Transferu Technologii Sp. z o.o., Wrocław; ul. Skwierzyńska 21 Poland Fax info@quantum.com.pl Support support@quantum.com.pl 5