SLA 99,5% – so what?

SLA na poziomie 99,5% robi wrażenie, prawda? Przy okazji dyskusji pod wpisem u Boniego poleciało 99.5% jako synonim jakości (czegoś tam). Co z kolei skłoniło mnie do sprawdzenia, jak to się ma do danych dotyczących dostępności łącza, które wystawiam przy pomocy PUM. No i w skrócie: 99,5% dostępności w skali miesiąca to żaden wyczyn.

Na początek disclaimer: nie jest to wyraźnie napisane w FAQ, ale z tego co się dowiedziałem od autorów/supportu. Uptime Robot w wersji darmowej nie zlicza (poprawnie?) uptime dla okresu powyżej jednego miesiąca. Co niestety nie przeszkadza mu zwracać jakichś wartości dla okresów powyżej 30 dni.

The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year. And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).

I jak widać z powyższego, All uptime to tak naprawdę, w przypadku planu darmowego, uptime dla poprzedniego miesiąca.

Spójrzmy na the domek. Komputer Linuksem, dokładnie, Seagate Dockstar robiący za router, więc trochę embedded w porównaniu z typowym PC, czyli bardziej niezawodny. Za to z dyskiem w kieszeni USB, bez jakiegokolwiek podtrzymania prądu przy pomocy UPS. Łącze przez wiekowy modem USB, 3rd party dostawca over linia TPSAOrange (BSA).

Aby było weselej: połączenie resetowane raz dziennie, skrypt podnoszący/sprawdzający uruchamiany co 4 minuty , a PPPoE trochę wstaje…

I cała ta rzeźba, łącznie z przerwami po stronie 3rd party usługodawcy, Orange, dostawcy monitoringu (czyli Uptime Robot), zwłoką przy odświeżaniu dyndns (monitoring jest po domenie) i problemami w globalnym internecie daje radę. Generalnie, bo oczywiście są miesiące, że nie da.

SLA 99,5% my ass… 😉

[1] Nie pamiętam już, czemu tak, zdaje się, że musiał mieć chwilę na sprawdzenie albo ubicie pppd. Albo nie chciało mi się pisać obsługi lockfile’a, bo parę minut przerwy w nocy i tak jest pomijalne w tym zastosowaniu…

Dlaczego nie kupię Raspberry Pi

Pierwsze egzemplarze Raspberry Pi dotarły parę dni temu do nabywców w Polsce, pojawiają się pierwsze recenzje i zachwyty. FullHD, mało prądu[1], działa Linux – wydawać by się mogło, że pełna sielanka. Jednym okiem śledzę nowinki ze świata komputerów opartych na ARM, szczególnie pod kątem Linuksa. Mam domowy serwerek (głównie router) z Debianem działającym na Dockstarze. I już wcześnie pisałem, że sytuacja ARM i Linuksa nie jest różowa.

Od czasu tego ostatniego wpisu minęło trochę czasu, sytuacja stopniowo poprawia się, jeśli chodzi o wsparcie dla Linuksa. W Debianie pojawi się (prawdopodobnie już we Wheezy) nowa architektura ArmHardFloatPort. Stwierdziłem, że sprawdzę, czy przypadkiem da się z niej skorzystać na Dockstarze (nie, nie da się), w międzyczasie zakręciłem się w oznaczeniach, więc zadałem pytanie na forum Dockstara, a jedna z odpowiedzi bardzo otworzyła mi oczy na sytuację i jest inspiracją dla tego wpisu. Gorąco polecam lekturę całego wątku w oryginale, ale dla tych, którzy nie mają czasu lub możliwości skrót głównej myśli poniżej.

Otóż Raspberry Pi jest drogi i przestarzały. Niby miało być 35 dolarów, ale w praktyce jest to minimum 35 euro. Za sprzęt bez portu SATA, z 256 MB RAM (piszcie co chcecie, ale to stanowczo za mało na desktop, pracowałem ostatnio na niecałych 400 MB), bez obudowy (pewnie prędzej czy później pojawią się za ok. 10 dolarów, plus wysyłka) i bez zasilacza. Przede wszystkim jednak jest to sprzęt, na którym nowa, wydajniejsza architektura nie zadziała w ogóle. Z tego samego powodu nie zadziała na Raspberry Pi Ubuntu.

Pojawiła się alternatywa w postaci Gooseberry (płyta z tabletów), która jest oparta na nowszym, wspierającym armhf procesorze i oferująca 2-3 razy większą wydajność, 512 MB RAM, ale też ma wady, przede wszystkim cenowe, szerzej omówione w wątku na forum. Ogólnie myśl jest taka: Raspberry Pi jest tragicznie przestarzałe i drogie, Gooseberry to goła płyta z tableta, dopłacając minimalnie, można mieć tablet, czyli kompletne urządzenie, z ekranem, obudową, zasilaczem itd. Ale sugestia jest taka, by kupić po prostu Mele A2000 za 90 dolarów (z wysyłką do Polski). Trochę drożej ale dostajemy 512 MB RAM, port ethernet, normalne SATA, HDMI, VGA i obudowę. I – przede wszystkim – nowszą architekturę, nad którą pracuje większość developerów różnych dystrybucji Linuksa.

Oczywiście, zapewne pojawi się, przynajmniej początkowo, jakaś dystrybucja wspierająca Raspberry Pi. Można też będzie samemu rekompilować z odpowiednimi aktualizacjami. Ale powoli będzie się to coraz bardziej rozjeżdżać między główną linią Linuksa na ARM i wymagać coraz więcej pracy w utrzymaniu.

Oczywiście mówię o zastosowaniach, gdzie rozmiar płytki i pojedyncze W różnicy w poborze prądu mają drugorzędne znaczenie i bardziej o desktopach. Mój Dockstar jest równie przestarzały, ale jako router i domowy serwer pewnie będzie wystarczający jeszcze długie lata. Ale nigdy nie był kupowany z myślą o podłączaniu do niego monitora i korzystaniu z graficznego środowiska.

[1] No dobrze, niby mało, ale lepiej się dało. Prosta (ideowo, niekoniecznie prosta do wykonania, bo wymaga lutowania na płytce) modyfikacja pozwala na zmniejszenie poboru prądu w Raspberry Pi o 25%.

UPDATE: Pojawiła się kolejna alternatywa dla Raspberry Pi – ODROID-X. Co prawda aż 130 dolarów za gołą płytkę, ale czterordzeniowy procesor 1,4 GHz, 1 GB RAM i mocne GPU, więc chyba najbliżej sensownego desktopu. Oczywiście nowa architektura procesora ARM. Raczej nie będę już aktualizował tego wpisu o kolejne sprzęty – ten pojawił się po prostu krótko po zamieszczeniu wpisu.

UPDATE: Długo nie trzeba było czekać – na Allegro już pojawiają się praktycznie nieużywane egzemplarze Raspberry Pi. Ceny nie podam, bo nie ma kup teraz, tylko licytacja (ok. 100-150 zł w tej chwili). A sprzedający nowe sztuki życzą sobie 250 zł i więcej za gołą płytkę. Plus minimum 20 zł za pseudoobudowę (dwie płytki akrylu z przerwą) i 40 zł za „oryginalny zasilacz”. W zamian jedynie faktura i szybsza dostawa. No i ew. gwarancja/rękojmia. Tyle, że to drożej niż Mele A2000. Przy okazji, info dla oszczędzających: pojawiła się wersja oznaczona Mele A100, która jest wykastrowana z SATA, ale za to 10 USD tańsza. IMO nie warto, chyba, że ktoś na pewno nie chce dysku podłączać.

Seagate Dockstar jako router.

Jakiś czas temu było o HP T5520 jako routerze, który działał i byłem z niego zadowolony, ale trzeba poznawać nowe rzeczy (w tym przypadku: sprzęt na ARM). Poza tym, z T5520 można zrobić nieco więcej, niż tylko router (ma wyjście audio, w połączeniu z MPD będzie pewnie robił za odtwarzacz radiowy, shell i NAS w innej lokalizacji). Jasne, mogłem dołożyć do Dockstara kartę dźwiękową na USB, ale ciekawiło mnie też, czy modem USB (Sagem F@st 800) zadziała na ARM.

Wybór padł na Seagate Dockstar, bo był to tani sprzęt (wówczas ~100 zł, obecnie dwa razy drożej), o niezłych parametrach (128 MB RAM, procesor 1,2 GHz). Jako alternatywa dla T5520 w tym zastosowaniu – teoretycznie idealny. I – z racji architektury ARM – znacznie bardziej energooszczędny (maksymalnie poniżej 10W poboru prądu). Last but not least – Dockstar obsługuje niemodyfikowanego Debiana.

Od zakupu do uruchomienia minęło sporo czasu. O ile instalacja Debiana była bezproblemowa, o tyle działało to nieco losowo, więc dwa podejścia spędziłem na ustalaniu, co się sypie, że czasem wstaje z Debianem, a czasem z oryginalnym systemem. W końcu doszedłem, że winny był pendrive. Faktycznie, po wymianie na inny zaczęło działać stabilnie i można było się zająć przeniesieniem konfiguracji.

Przeniesienie było proste, podłączenie modemu i… zonk. Okazało się, że debianowe kernele nie są równe, konkretnie brakowało modułu br2684. Niby żaden problem przekompilować kernel, ale jeśli mam to robić na niedużym pendrive zamiast dysku, albo crosskompilując, to tak różowo nie jest. Ostatecznie zgłosiłem błąd dotyczący braku br2684, który szybko został poprawiony.

Niestety, poprawka wyszła dla kernela w wersji 3.0 z experimental. Jakoś nie ciągnęło mnie do wrzucania na produkcyjną (choć prywatną) maszynkę takiego wynalazku, tym bardziej, że nie sam kernel trzeba wymienić. A cokolwiek innego wiązało się z kompilacją… No dobrze, niech będzie. Skoro już kompilować, to jednak 2.6 ze Squeeze. I natywnie, na Dockstarze (jakoś się na tym pendrive zmieściło po rozpakowaniu).

Pobrane źródła, pobrane i nałożone patche, korekta pliku konfiguracyjnego, make-kpkg… I zonk z kryptycznym komunikatem (niestety nie zanotowałem). Okazuje się, że make-kpkg nie potrafi sam wykryć architektury, na której jest uruchamiany. Po podaniu –arch armel (dzięki przewodnikowi po crosskompilacji dla Dockstara) poszło dalej, choć niewiele. Tym razem winne lzma i cannot allocate memory (OSLT; mimo sporego swapa – IIRC 160 MB) i tyle. A przecież nie tak dawno kompilowałem kernele na maszynach z 64 MB RAM…

Na szczęście ww. przewodnik po crosskompilacji ładnie opisuje jak stworzyć środowisko i krok po kroku wyjaśnia, jak zrobić kernel. Stwierdziłem, że skoro akcja pewnie będzie się powtarzać, to warto mieć coś szybszego do kompilacji… Opis jest bdb, używanie środowiska do crosskompilacji proste. Wystarczyło poczekać parę h (tak, kernel debianowy to krowa z masą zbędnych opcji, ale stawiałem na kompatybilność i nie chciałem się bawić…) i kernel gotowy.

Kolejna ARMowa ciekawostka to instalacja. Zwykłe dpkg -i nie wystarcza. Jak widać w przewodniku po crosskompilacji kernela, trzeba jeszcze odczynić ręczną magię z uImage i uInitrd. Z pozytywów: wstało od kopa. Jest moduł, ale… nadal nie działa. Tym razem po podłączeniu modemu masa wpisów w stylu:

ATM dev 0: usbatm_submit_urb: urb 0xc6c50b40 submission failed (-28)!

Oczywiście modem się nie łączy… Googlanie po całości wpisu nie dało efektów, ale ostatecznie, szukając po fragmentach, trafiłem na ten błąd dla OpenWRT, który sugeruje wymuszenie bulk mode. Niby wolniejsze przy większych prędkościach, ale dla łącza 1 Mbps nie stanowi. Zresztą, innych pomysłów brak, zatem:

echo "options ueagle-atm altsetting=0,0,0,0" > /etc/modprobe.d/eagle-usb.conf

W końcu działa. Nawet się połączył. Małe dopieszczenie konfigów i w końcu maszynka przeniesiona. Generalnie z odkrytych wad Dockstara: nie ma RTC, więc po restarcie startuje bez aktualnej daty i godziny. Oczywiście instalacja ntp załatwia problem po nawiązaniu łączności z Internetem, ale przy ppp chwilę to trwa i przez tę chwilę wpisy w logach będą ze złą datą.

Inna uwaga odnośnie Debiana i ARM: nie jest to tak dopracowane jak architektury i386 i amd64. Generalnie działa, ale zamiast po prostu działa, trzeba bawić się w podawanie opcji (make-kpkg) lub nawet robienie części rzeczy ręcznie (initrd).

Parę przydatnych/użytych linków, niekoniecznie występujących w treści:

Wiki Debian on Dockstar

Zgłoszenie błędu z modemem USB dla OpenWRT

Komunikaty błędu na Dockstarze dotyczące Sagem F@st 800

Opis przygotowania środowiska do crosskompilacji i zrobienia nowszego kernela dla Dockstara

Póki co, trwa niezbyt obiecująco wyglądające (wygląda, że raz się wywalił z powodu loadu…) wygrzewanie sprzętu.

UPDATE: Jednak działa stabilnie od blisko dwóch tygodni. Prawdopodobna przyczyna ww. wywałki – błędy filesystemu (pewnie z czasu instalacji, kiedy nie był read only jeszcze). Po fsck, naprawieniu błędów i reboocie bez problemu.

UPDATE2: W jednym z kolejnych wpisów opisuję jak zrobić na Linuksie router Wi-Fi. Po dołożeniu karty Wi-Fi na USB Dockstar się nada.