Open-iscsi i offloader broadcom

Ostatnio dostałem w swoje łapki dwie macierze EMC VNX5300 (block). Na jakość dokumentacji jaką wyprodukowało spuszczę zasłonę milczenia (przynajmniej na razie). Skupię się za to na podłączeniu systemów do tego cuda. Mam kilka serwerów do podpięcia. Wszystkie mają po cztery interfejsy sieciowe Broadcom BCM5709S wyposażone w offloader iSCSI. Walcząc z jednym z wielu problemów dot. tej macierzy i jej uruchomienia przetestowałem działanie z i bez niego na centosie i potwierdziłem fakt, że działa i że działanie przynosi pozytywne efekty dając około 17% wydajności więcej, Na tym etapie mógłbym zakończyć opowiadanie, ale klient używa Debiana. iSCSI w trybie programowym działa poprawnie. Przy przełączeniu w tryb hardware (moduł bnx2i i cnic) nawet nie nawiązuje połączenia. Po dłuższej analizie i poszukiwaniach udało się ustalić, że Offloader do pracy potrzebuje modułu iscsiuio z którym przez netlink ma się komunikować iscsid. Niestety Debian nie dostarcza iscsiuio. Okazuje się, ze inne dystrybucje podchodzą do problemu tak, że biorą iscsiuio, open-iscsi i pakują to do kupy jako w paczce iscsi-initiator-tools. Dobra... ale skąd pobrać źródła iscsiuio? Aplikacja jest dewelopowana przez Broadcom i "dostępna w wybranych dystrubcjach". Nigdzie nie można od tak pobrać sobie kodu źródłowego mimo iż jest on wydawany na GPL, ale w zasadzie można użyć wersji, którą mają owe inne dystrybucje. Wiedząc co mniej-więcej trzeba zrobić założyłem bug report. Oto on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699240. Nastąpiła wymiana maili z maintainerem open-iscsi w debianie którym jest Ritesh Raj Sarraf. Podobnie jak ja nie mógł znaleźć źródeł. Zgodził się, że dobrze by było gdyby ten moduł znalazł się w Debianie jednak sam nie ma dość motywacji by to zrobić bo nie ma takiego sprzętu. Zaproponowałem, że pomogę on zaproponował, że może warto stworzyć oddzielny pakiet i może mnie zarekomendować jako nowego maintainera w społeczności. Nawet mi się to spodobało, zważywszy  że i tak planuję tam dołączyć jako maintainer LMS'a. Zapytałem czy powinienem utworzyć repozytorium na github czy może Debian ma jakieś miejsce na takie wypadki, on zaproponował bym uderzył w tej sprawie do Broadcoma. Nie sądziłem, że się uda. W sumie to bardzo duża firma. Nie mniej jednak spróbować warto. Wysłałem maila dwoma kanałami. Jednym oficjalnym, w którym zapytano mnie jakiej dystrybucji używam, bo oni wspierają SLES i RHEL i zamknęli zgłoszenie nie czekając na odpowiedź. Drugim kanałem były adresy mailowe twórców iscsiuio wygrzebane z changelogów. Odpowiedział mi Eddie Wai podając na tacy linka do aktualnego źródła iscsiuio, który jak się okazało jest patchem na open-iscsi adresatem była też grupa google projektu open-iscsi. https://groups.google.com/forum/?fromgroups=#!topic/open-iscsi/pdK7Xw45i-k. W ten oto sposób twórca open-iscsi Mike Christie zgodził się dołączyć iscsiuio do open-iscsi. Co ostatecznie udostępni offloader broadcoma wszystkim, a nie tylko wybranym dystrybucjom.

Przede mną jeszcze tylko testy, które już wstępnie uzgodniłem z klientem. Na Debian Wheezy jest już stanowczo za późno, ale kolejne wersje pewnie już będą miały wsparcie. Tym ruchem może świata nie uratowałem. Lubię natomiast myśleć, że byłem inicjatorem malutkiego kroczka popychającego cywilizację na przód.

Przeładowanie - co mówi top?

Czasem jakaś maszyna dostanie zadyszki - to zrozumiałe. Rzadko jednak da się osiągnąć taki efekt.

Najbardziej podstawowym parametrem w najbardziej ogólny sposób opisującym stan obciążenia systemu jest "load average" czyli średnie obciążenie. Są to trzy liczby i w wielkim skrócie oznaczają one średnią ilość procesów/zadań/wątków oczekujących w kolejne na czas procesora. Kolejne wartości liczbowe pochodzą z różnych okresów dla jakich liczona była średnia. Pierwszy to minuta (mamy problem tu i teraz). Druga to pięć minut (już trochę trwa), ostatnia to minut piętnaście (co gorsza problem narasta). Wg doświadczenia i zdrowego rozsądku problemy wydajnościowe najczęściej zaczynają się w momencie gdy wartości tych liczb przekraczają liczbę rdzeni dostępnych w systemie. Potrafi dojść wtedy do lawinowego wzrostu obciążenia, co jak byk widać w tym wypadku. Load powyżej stu to rzadkość. W tym wypadku mamy prawie dwa tysiące.

Jako bonus dodam, że Rzadko zdarza się też by było więcej niż kilkadziesiąt zadań. Tutaj mamy ponad dwa tysiące. Jednym słowem bombowy dzień.

W trzecim wierszu topa znajdują się statystki procesorów. Często spotykam się z sytuacją w której okazuje się, że nawet relatywnie doświadczony admin ma problemy z rozszyfrowaniem do czego są te wszystkie procenty, a wiedza często ogranicza się do trzech podstawowych, choć czasem i tutaj są braki. Są to po kolei:

us - użytkownik
sy - system
ni - zadania z ujemnym priorytetem
id - bezczynność
wa - operacje I/O
hi - przerwanie sprzętowe
si - przerwanie programowe
st - "ukradzione"

Innym razem może opiszę dokładnie o co chodzi w każdej z tych kategorii.