Ile może kosztować prosty skrypt powłoki?

Wyobraźmy sobie, że mamy sieć rozległą, złożoną z wielu elementów aktywnych IP. Elementy oraz łącza podkładowe ulegają czasem awarii. Postanawiamy stworzyć proste narzędzie monitorujące - skrypt powłoki:

• pobierający z bazy danych wykaz urządzeń,
• testujący pingiem ich dostępność,
• wysyłający e-mail do administratorów w przypadku, gdy któreś urządzenie jest nieosiągalne.

Zaniedbajmy fakt, że jest to klasyczne wynajdywanie koła. Ile może kosztować napisanie czegoś takiego?

Sprytna odpowiedź brzmi: to zależy. ;)

Zwinny administrator, posługujący się biegle powłoką i językami skryptowymi, popełni w tzw. międzyczasie jednolinijkowca. Jest to bezkosztowe lub bardzo tanie - powiedzmy 0,1 tys. PLN.

Jeśli zrobi to pracownik zewnętrzny, dojdzie jeszcze prowizja handlowca, krótka dokumentacja dla klienta, prezentacja "jak to działa" - powiedzmy że do 2 tys. PLN.

Co jednak, gdy rzecz dzieje się w środowisku objętym zarządzaniem zmianami? Warsztaty wymagań z użytkownikami, dokument analizy, kodowanie, dokumentacja i testy odbiorcze. Całkowity koszt może wynieść bez problemu 10 tys. PLN.

A gdyby to nie było w kraju PLN-ów lecz w którymś zamożnych krajów Europy Zachodniej... ;-)


Do czego zmierzam? Czy zarządzanie zmianami to źródło zła? Odpowiem: to zależy! ;)

Można wysnuć z tego różne wnioski:

1. Rzeczy, które są proste i tanie w realiach małej firmy, niekoniecznie są takie w realiach dużej firmy.
2. Uwzględniając powyższe, w realiach dużej firmy zakup bardzo drogiego, ale gotowego oprogramowania może być i tak tańszy, niż wdrażanie i wsparcie (TCO) dla oprogramowania darmowego.
3. Narzut wprowadzany przez różne standardy i metodyki może podnieść koszty rozwiązania np. o 2 rzędy wielkości, nie zawsze poprawiając jakość rozwiązania.
4. W realiach dużej firmy te podwyższone koszty mogą być wciąż zaniedbywalne, a bardziej zwinne firmy zyskują dzięki temu szansę zarobkowania (brutalnie rzecz umując, pasożytują na bezwładnej korporacji sprzedając jej prosty software za wielkie pieniądze).
5. Mnóstwo pieniędzy może zostać zmarnotrawionych na wszelkie formy zarządzania i pośrednictwa, a nie na samo rozwiązanie - jest to więc dobre miejsce na szukanie oszczędności.

VPN z OpenSSH

Kiedy potrzebujemy zestawić między dwoma sieciami VPN na publicznej sieci IP, wybór pada zwykle na jedno z dwóch rozwiązań:

• SSL VPN
• IPsec VPN (tryb tunelowy)

W przypadku IPseca mamy implementację na poziomie jądra systemu operacyjnego i opcjonalnego demona do wymiany kluczy, np. racoon, isakmpd lub inny.

Konfiguracja IPseca jest zwykle dość zagmatwana i można spotkać problemy ze współpracą różnych implementacji ;) toteż administratorzy lubią SSL VPN-y, które "po prostu działają".

Implementacja SSL VPN działa w całości w przestrzeni użytkownika, posiłkując się sterownikiem jądra dostarczającym pseudointerfejsu tunelującego (np. tun). Jedną z najpopularniejszych implementacji SSL VPN-a jest OpenVPN.

W tym wpisie chciałbym jednak pokazać inny wariant SSL VPN-a, nieco mniej znany, ale za to oprogramowanie mamy już w systemie więc zwykle da się to odpalić "od ręki" - mowa o OpenSSH. Nie, nie chodzi o przekierowywanie portów. Od wersji 4.3 (2006 rok) mamy dostępną opcję -w, która umożliwia zestawienie VPN-a z użyciem pseudointerfejsu tun/tap.

Aby to działało, musimy włączyć w serwerze SSH następujące opcje: PermitTunnel i PermitRootLogin.

W celu zilustrowania uruchomię sobie 2 maszyny wirtualne: jedną z Linuksem (serwer) i jedną z OpenBSD (klient). Maszyny mają ze sobą bezpośrednią łączność po IP.

debian:~# grep -i permittunnel /etc/ssh/sshd_config

PermitTunnel yes
debian:~# /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.

Następnie łączę się z OpenBSD do Linuksa:
open# ssh -NTf -w any:any 192.168.1.182

root@192.168.1.182's password:

W wyniku mamy po obu stronach pseudointerfejsy tun i możemy je zaadresować:

open# ifconfig tun
tun3: flags=51 mtu 1500
priority: 0
groups: tun

debian:~# ip a sh dev tun0

5: tun0: mtu 1500 qdisc noop state DOWN qlen 500
link/[65534]

debian:~# ip a add 172.16.1.2 dev tun0 peer 172.16.1.1
debian:~# ip link set tun0 up


open# ifconfig tun3 172.16.1.1/32 172.16.1.2


Testujemy... działa:
open# ping -c 2 172.16.1.2

PING 172.16.1.2 (172.16.1.2): 56 data bytes

64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=1.785 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=7.274 ms
--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.785/4.529/7.274/2.745 ms

Pozostaje ustawić ruting do sieci zdalnej (i opcjonalny NAT). Można także wymusić (klient, opcja Tunnel) użycie pseudointerfejsu tap, czyli emulację łącza Ethernet.


Obecne w OpenSSH wsparcie dla tworzenia szyfrowanych tuneli może być w niektórych sytuacjach znacznie lepszym rozwiązaniem niż przekierowywanie portów. Mamy możliwość transportowania innych protokołów niż TCP, a nawet ramek Ethernet (bridge poprzez VPN). Jeśli potrzebujemy uzyskać dostęp do wielu systemów w zdalnej sieci, może to być prostsze rozwiązanie niż przekierowywanie długiej listy portów. Przekierowanie portów może też utrudnić korzystanie z wirtualnych serwerów WWW (name-based) - tutaj nie mamy tego problemu. Jednak aby się tym pobawić, musimy mieć prawa roota zarówno po stronie serwera, jak i klienta.

Gorzej, ale czasem szybciej

Natknąłem się niedawno na ciekawy, a do tego świeży (czerwiec 2010) artykuł "You're Doing It Wrong", który popełnił znany z asertywnych wypowiedzi deweloper FreeBSD i Varnisha, Poul-Henning Kamp.

Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.

Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.


Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)

Jak hartowała się wirtualizacja

Popełniłem ostatnio kilka bardziej technicznych wpisów, a miały być przecież wynurzenia. ;-)

Jednym ze słów-kluczy, które padły we wpisie o meetBSD, jest wirtualizacja. Ta wspaniała wirtualizacja, dzięki której możemy skonsolidować wiele mielących wiatrakami powietrze serwerów w jedną fizyczną maszynę i uratować zasoby planety; dzięki której możemy powoływać i niszczyć środowiska systemowe (np. do testów) kilkoma kliknięciami myszki.

Pamiętam, że dawno dawno był taki numer PCkuriera, w którym po raz pierwszy ujrzałem VMware, jaskółkę zwiastującą ofensywę wirtualizacji. Przeczesałem dziś metry żółtych okładek na półkach i znalazłem: numer 18/99 z 2-go września 1999 r.

Strona 30, w kategorii Oprogramowanie/Emulatory czai się recenzja Artura Wyrzykowskiego "VMware 1.0. Windows pod Linuksem". Znamienne, że produkt był właśnie w wersji dla Linuksa - "dla Windows NT 4.0 i 2000 VMware przygotowało analogiczny emulator (obecnie jeszcze w wersji beta)". Było to de facto obecne Workstation i kosztowało 299 USD. Autor przeprowadził testy SYSmarkiem, środowisko bez wirtualizacji było o 70-100% szybsze. Zastosowania? Bardzo niszowe. :) Dla kogoś, kto z jakiegoś powodu pracuje tylko pod Linuksem, a musi uruchomić jednocześnie np. MS Windows dla jakiejś specyficznej aplikacji np. Płatnika...

Dziś do zabawy w wirtualizację na desktopie mamy za darmo choćby VMware Player czy Oracle Virtualbox. Prawdziwy biznes robi się na wirtualizacji datacenter, choć i tam coraz więcej można dostać w gratisie.

Dla oddania kontekstu historycznego, kilka smaczków z tego numeru:

• str. 6 - "koszt rejestracji nazwy w domenie .PL to obecnie 300 zł (...) co roku"
• str. 12 - "Usługi katalogowe dziś i jutro", czyli NDS vs. AD - dziś już chyba nie ma wątpliwości, kto wygrał ;)
• str. 18 - "Linux od Corela", pokaz przedpremierowy ś.p. Corel Linuksa oraz Inprise ;) Delphi 5, do tego "Amerykański Departament Handlu poszukuje technologii szyfrujących, z których wybierze jedną jako oficjalny standard AES"
• str. 37 - "TCH Components wprowadził do sprzedaży (...) dyski o pojemności 18GB"
• str. 38 - "Linia komputerów ZETAN, produkowanych przez grupę ZETO (...) wzbogaciła się o komputer wyposażony w procesor Pentium III 600MHz. Zastosowano w nim płytę główną z chipsetem BX, dysk o pojemności 8,4GB oraz 128MB RAM"
• str. 57 - test monitora LCD IBM T55A o przekątnej 15'', cena? jedyne 5700 zł + VAT
• str. 58-59 - zestawienie cen modemów i faksmodemów, ceny rzędu 300-500 zł, ale pojawiają się winmodemy za 149 zł ;)
• str. 60 - informacja o ICQ99b, "w tej chwili baza użytkowników tego pakietu (...) przekracza 40 mln"
• str. 68 - "Bankructwo Iridium. Kosmiczne długi", "Linux na giełdzie. Cena akcji RedHat (...) wzrosła pierwszego dnia notowań o 370%"

Pamiętam... że dawno dawno dawno temu był tak numer C&A, w którym był test emulatora PC na Amigę... ale nie, ta szafa jest zbyt zakurzona.

meetBSD 2010 Kraków

W dniach 2-3 lipca 2010 odbyła się w Krakowie konferencja meetBSD. Wśród prelegentów dominowali goście zagraniczni, w tym deweloperzy systemu FreeBSD. Poziom merytoryczny był wysoki, ale i momentami "ciężki" gatunkowo. Może właśnie dlatego na sali wykładowej było wiele pustych miejsc? Sama sala była zresztą świetna, podobnie jak cały budynek Wydziału Matematyki i Informatyki UJ.

 

Społeczność BSD jest wyraźnie mniejsza niż Linuksowa, także ta komercyjna. Zapewne dlatego Linux wyraźnie wyprzedza FreeBSD w niektórych obszarach. Są to m.in. sieciowa replikacja urządzeń blokowych (np. DRBD) oraz możliwości wirtualizacji. Na konferencji swoje prelekcje mieli autorzy rozwiązań adresujących te luki: HAST-a (Paweł Jakub Dawidek) i VImage (Marco Zec); są one w dość wczesnej fazie rozwoju, ale mają szansę na upowszechnienie wraz z kolejnymi wydaniami linii FreeBSD 8.x.

HAST
HAST odpowiada funkcjonalnie DRBD - replikuje dyskowe urządzenia blokowe (providerów GEOM). Na ten moment implementuje tylko tryb replikacji synchronicznej i nie wspiera pracy multimaster. Według autora jest już jednak w pełni funkcjonalny.

VImage
VImage to wirtualizacja stosu sieciowego. Pamiętam jeszcze patche do FreeBSD 4.x - wówczas było to rozwiązanie zaskakująco zaawansowane, ale chyba wyprzedziło zapotrzebowanie użytkowników. ;) Obecnie VImage zintegrowane jest z oficjanym jądrem (ale nie jest domyślnie wkompilowane) i wraz z jailami stanowi odpowiednik linuksowego OpenVZ. VImage nie wspiera jeszcze pf-a, ale wspiera ipfw i IPsec. Według autora możliwe są problemy ze stabilnością - feature ma status experimental.
Uwagę zwracało graficzne narzędzie do projektowania topologii wirtualnych maszyn z magicznym przyciskiem do aplikowania zaprojektowanych zmian na systemie. Widać, że autor używa tego do symulowania różnych topologii sieciowych i zabawy z protokołami rutingu (w puli jaili, każdy z osobnym stosem sieciowym, biegały Quaggi).

High-speed traffic
Szczególnie zainteresował mnie wykład dotyczący wysokowydajnego rutowania i policowania ruchu abonenckiego na FreeBSD. Nikolay Aleksandrov prezentował rozwiązanie wydewelopowane wewnętrznie dla potrzeb jednego z bułgarskich ISP (warto sprawdzić ofertę - jesteśmy 100 lat za Bułgarami;)):

• zmodyfikowali sterownik karty sieciowej Intela, stworzyli pewien odpowiednik Netgrapha
• zrównoleglili polling na wiele rdzeni CPU i kart

i w ten sposób praktycznie pominęli stos sieciowy systemu - przy pomocy specjalizowanych "węzłów" dopasowują i przekładają ramki pomiędzy VLAN-ami i portami kilku 4-portowych kart 1Gbit, przy okazji go kolejkując. Jako że przepuszczają przez tą maszynę także ruch między abonentami, mają naprawdę duże obciążenie - jeśli dobrze zapamiętałem (slajdów jeszcze nie ma) przy kilkunastu tysiącach abonentów jest to około 2Mpps, 2Gbps ruchu Internetowego i 20Gbps wewnętrznego. To wszystko przycinanie i równoważone w około 200 tys. kolejek (jeden z ich węzłów do procesowania pakietów) na dość zwyczajnej platformie serwerowej Intela z Xeonami przy stabilnym 50% obciążeniu. Aha, zrobili hook do BPF-a (por. wpis o ringmapie), przez co możliwa jest wydajna inspekcja ruchu. Zabawne, do jak ciekawych rzeczy można doprowadzić brak pieniędzy na "profesjonalne rozwiązania". Niestety... kod nie jest na razie publicznie dostępny. ;)

Wieczorny Social Event z koncertem był bardzo przyjemny, a darmowe piwo lało się strumieniami. :P