Przedłużanie sobie... wifi

Ostatnio uznałem, że moje wysłużone WRT54GL (1.1) z Tomato na pokładzie nie jest wystarczająco szybkie, pora je więc czymś zastąpić. Wybór padł na Asusa 1200 AC.
Na koniec dnia i tak rozbijam się o gówniany internet a'la Plus: 1 BTS LTE na kilka wsi, gdzie na co drugim domu wiśi miska z napisem "Polsat" powoduje, że oferta "Smart Dom" wcale nie jest już taka smart.  Ale o tym innym razem.
Sam router, jak twierdzi producent, ma mieć super-extra zasięg, bo ma "brust shaping" i w ogole jest mega inteligentny. No cóż... Na obydwu zakresach zasięg ma mniej więcej o 40% słabszy niż stareńki Linksys. Ale "na wprost", telewizor ma pełny zasięg więc go zostawiłem, a połączenie jest stabilne.
Problem polega na tym, że w dalszej części domu, sygnału, choćby nie wiem jak inteligentnie ukształtowanego nie ma, co spotkało się z głośnymi protestami nastolatka, który (myśli, że o tym nie wiem) w nocy ogląda na telefonie... to co nastolatki na telefonach po nocach oglądają.
Na szczęście dom jest okablowany ethernetem, więc mogłem dostawić starego linksysa w okolicy, gdzie nie docierał sygnał.
Asus ma dwa SIDy: Coś i Coś_5G (czyli 5GHz) Cały przepis w takiej sytuacji sprowadza się do :

• Wyłączenia na starym routerze serwera DHCP (za to odpowiedzialny jest Asus)
• Ustawienia tego samego SIDu (sieci 2.5GHz), hasła i szyfrowania co na głównym routerze.
• Podłączenia nowego-starego routera w miejscu, gdzie będzie dawał dobry zasięg.

Trochę gorzej sprawa się ma, gdy kabla ethernet nie ma - wtedy potrzebny jest ten przepis:
http://www.howtogeek.com/104007/how-to-extend-your-wireless-network-with-tomato-powered-routers/

Fedora 24 i ThinkPad W541 - Huwaei E3372

Walka rozpoczęta.
Fedora 24 wyjdzie co prawda za tydzień, ale jak to tak - nowy ThinkPad ze starym systemem?
Nie wytrzymałem i postanowiłem zainstalować betę. F24 już od czasu rawhide męczę pod KVMem, ale teraz nadarzyła się okazja, więc postanowiłem  zainstalować ją na gołym żelazie.

Rożne, rzeczy dzieją się z tym sprzętem / systemem, więc postanowiłem notować moje małe zwycięstwa a pewnie i porażki.
Pierwsze jest zwycięstwo - odpaliłem modem, Huawei E3372. Niby nic takiego - od 2 lat działa bez zarzutu z Fedorami 21 - 23.
Same  problemy z modemem w trybie mass storage rozwiązano... 6 lat temu ? To był z resztą decydujący powodód, dla którego porzuciłem RedHata (wówczas 5) na rzecz Fedory... bodajże 14.

Otóż w Fedorze 24 jest niedoróbka - mam nadzieję, że będzie poprawiona - W tej wersji modem cofnął się do czasów RedHata 5 i usb_modeswitch. A oto sposób na ponowne przekonanie go, że modem to modem. Choć w tym wypadku modem to.. karta ethernet :-)

1. Podłączyć modem.
2. Znaleźć w dmesg zaznaczone wpisy:

3. Mamy zatem vendora i produkt. Do pełni szczęścia, trzeba określić gdzie się podłączył. Z pomocą przychodzi lsusb:

4. Jak widać modem podłączył się jako mass storage device. To taki sposób na dostarczanie driverów dla systemów które ich nie mają - Windows widzi go najpierw jako dysk z driverami, a one przestawiają go potem w odpowiedni tryb. Linux do tego celu używa polecenia usb_modeswitch:

5. I w zasadzie gotowe. Jeszcze tylko trzeba sprawdzić w lsusb czy się udało.

Brak Mass storage w opisie, oznacza, że system widzi już nową kartę ethernetową. Ten przepis powinien zadziałać też dla starszych/innych modemów.

Opisałem tego buga w fedorowej  bugzilli. Pewnie brakuje jakiegoś pakieciku. Ciekawe czy mi, czy nie ma go w repozytorium :-)

Kernel Same-page Merging - drobiazg, który cieszy

Wziąłem się trochę za OpenStacka. Konkretnie za Swifta, a konkretnie za Swifta jako cloud storage do TSMa.^H^H^H^H Spectrum Protect :-P. No i mam lekki problem. W sumie mam dwa komputery z w sumie 24GiB RAM. A żeby postawić to w miarę koszernie to potrzebuję: 16GiB RAM na samego TSMa (to akurat zabobon, daje radę na 12  zwłaszcza, że to testówka, 2x4GB na storage nody Swiftwa + 2 GiB na keystone. Swifty spróbuję zmieścić w 2x2GiB (testówka). To daje razem, w wersji minimum, jakieś 18GiB RAM na same wirtualki. Co zostawia jednemu hostowi 4 GiB na system i aplikacje a drugiemu... raptem 2GiB. Trochę mało zwłaszcza, że oba muszą działać w grafice, a jeden z nich (ten 16gigowy z TSMem) musi ciągnąc jeszcze napisane w javie+eclipse korpo Lotusy-Gniotusy. Na drugim w tych pozostałych 2GB muszę upchnąć LibreOffice i Chrome + X okien xterminala.
Wirtualizator to oczywiście KVM + qemu. Hosty to Fedory 23. Jądro Linuxa zawiera mechanizm KSM: Kernel Same-page Merge, który pozwala deduplikować pamięć. Całość została pomyślana jako metoda na oszczędzanie pamięci w wirtualizatorach, ale w zasadzie każdy może użyć funkcji madvice :-)
Żeby to włączyć wystarczy zainstalować pakiet:

• ksm - u mnie w takiej wersji: ksm-2.4.1-6.fc23.x86_64

A następnie włączyć usługę ksm.service.
Ale to za chwilę. Przyjrzyjmy się mojej pamięci RAM przed uruchomieniem maszyn wirtualnych:

Jak widać szału nie ma - standardowy zestaw aplikacji: Chrome, LibreOffice, Evolution wszystko w Gnome3. Istotne są dwie kolumny: VIRT - mówiąca ile pamięci aplikacja "myśli, że ma" i RES która pokazuje faktycznie, ile zajmuje dany proces w RAM.
Po odpaleniu dwóch maszyn wirtualnych (obie mają formalnie 2GB RAM, ale zaraz po uruchomieniu nie będą z tego korzystać) sytuacja wygląda następująco:

W sumie oba procesy qemu-system-x86 pożarły nieco ponad 1GB ramu.
Zobaczmy co się stanie po włączeniu KSM:

[marcinek@ajax:~]$ sudo systemctl start ksm

Pozwoliłem maszynom wirtualnym popracować około 10 minut. W tym czasie ksmd też nie próżnował i oto efekty:

Jak widać procesy qemu w sumie zjadły już 1341MiB (suma kolumn RES /1024). Zajętość pamięci hosta jest na poziomie 53%. Przy wyłączonym KSM, maszyny, które w sumie zajęły 1061MiB dawały utylizację RAMu hosta na poziomie 54%. Czary - zajętość ramu wzrosla, a utulizacja w % zmalała. 

Oczywiście pomiar nie jest super dokładny - musiałbym utłuc wszystkie procesy chodzące w tle, ale starałem się w nie nie zbytnio nie ignorować :-)

Jak sprawdzić ile zyskaliśmy na KSM? Trzeba zajrzeć do:

[marcinek@ajax:~]$ ls /sys/kernel/mm/ksm/

full_scans          pages_shared   pages_to_scan   pages_volatile  sleep_millisecs

merge_across_nodes  pages_sharing  pages_unshared  run

A konkretnie wyświetlić zawartość pliku pages_shared i pages_sharing:

[marcinek@ajax:~]$ cat /sys/kernel/mm/ksm/pages_shar*

47912

104698

Pierwsza wartość to liczba współdzielonych stron. Druga to oszczędność jaką mamy z zastosowania KSM. Obie wartości są w 4KB stronach, więc po przełożeniu na MB wychodzi odpowiednio: shared 187MiB, sharing 408MiB. To daje około 3% oszczędności pamięci hosta. Przy dwóch maszynach.
Za to przy trzech maszynach, każda po 2GiB RAM i pracy cały dzień, statystyki wyglądają już dużo ciekawiej:

Maszynki w sumie zajmują prawie 3GiB RAMu. Ale wskażnik pages_shared wynosi: 104898 co daje 409MB współdzielonych, przekładających się na 273768 stron (1069MB) zmapowanych. Zysk netto 660MB :-)

KSM i pliki z /sys/kernel/mm/ksm so opisane tutaj:

https://www.kernel.org/doc/Documentation/vm/ksm.txt

IPSEC VPN i problemy z ssh

Wbijałem się ostatnio do testowych maszyn, które zostały mi wystawione przy pomocy Shrew Software VPN. To cudo bazuje na IPSEC i IKE. W Fedorę jest wbudowany klient tego VPNu i jego postanowiłem użyć:

ike.x86_64 : Shrew Soft VPN Client For Linux

Od dostawcy VPNu dostałem profil PCF, który się prawie zaimportował. Nie wciągnął sobie adresu bramki, wartości klucza PSK i identyfikatora klucza. O ile bramka i identyfikator są tekstowe, o tyle PSK jest zaszyfrowany i musiałem go wyciągnąć oddzielnie od dostawcy. (cisco-decrypt tu nie pomaga :-\ )

Po zapięciu połączenia dostajemy interfejs tap0:

12: tap0: <BROADCAST,UP,LOWER_UP> mtu 1200 qdisc noqueue state UNKNOWN group default qlen 500
    link/ether 56:55:f3:de:c3:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.69/32 brd 192.168.254.69 scope global tap0
       valid_lft forever preferred_lft forever

Okazało się, że trafiam na ciekawy objaw: 

SSH do hosta zawisa na 

debug1: SSH2_MSG_KEXINIT sent.

Żeby było zabawniej jak robię telnet na port 22 tegoż hosta to SSH odpowiada.

Po googlaniu okazało się, że istotne jest MTU, które VPN domyślnie ustawia na 1380, co według różnych forów jest zbyt dużą wartością, dlatego zmniejszyłem ją do 1200. 

To problemu nie rozwiązało. Dalsze przeszukiwanie sieci pokazało jeszcze jedną sugestię. Linux wydaje się ignorować informacje o fragmentowaniu pakietów przez routery po drodze. Ale znalazłem zaklęcie, które to naprawia. miałem trochę szczęścia, bo wkleiłem je bez zrozumienia i działa :-)

firewall-cmd --direct --add-passthrough ipv4 -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Teraz muszę rozkminić jak to ubrać w regułkę, którą firewalld będzie łykał i monitorował, bo dodanie "passthrough" jest mało zgrabne.

TSM i pule typu DIRECTORYCONTAINER

Najprościej jest je zrobić z OC, ale ja wolę command line więc postanowiłem się nad tematem pochylić. Okazał się nieco prostszy niż sądziłem.

Na TSMie, którego konfiguruję będą się odbywać testy wydajnościowe, dlatego skonfigurowałem sobie aż 4 katalogi, które będą kontenerami:

/dev/mapper/tsmvg-tsmdirpool1lv     12T   34M   12T   1% /tsm/dircont1
/dev/mapper/tsmvg-tsmdirpool2lv     12T   34M   12T   1% /tsm/dircont2
/dev/mapper/tsmvg-tsmdirpool3lv     12T   34M   12T   1% /tsm/dircont3
/dev/mapper/tsmvg-tsmdirpool4lv     12T   34M   12T   1% /tsm/dircont4

Cała filozofia sprowadza się do napisania:

tsm: TSM>def stg dirpool1 stgtype=directory

Teraz trzeba dodać katalogi do tej puli:

tsm: TSM>define stgpooldir dirpool1 /tsm/dircont1,/tsm/dircont2,/tsm/dircont3,/tsm/dircont4

ANR3254I Storage pool directory /tsm/dircont1 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont2 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont3 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont4 was defined in storage pool DIRPOOL1.

Taaadaaam:

tsm: TSM>q stg

Storage         Device         Storage       Estimated       Pct       Pct      Hig-     Lo-     Next Stora-

Pool Name       Class Name     Type            Capacity      Util      Migr     h M-      w      ge Pool    

                                                                                 ig      Mi-     

                                                                                 Pct      g      

                                                                                         Pct     

-----------     ----------     ---------     ----------     -----     -----     ----     ---     -----------

ARCHIVEPOOL     DISK           DEVCLASS           0,0 M       0,0       0,0       90      70                

BACKUPPOOL      DISK           DEVCLASS           0,0 M       0,0       0,0       90      70                

DIRPOOL1                       DIRECTORY       49,144 G       0,0                                           

SPACEMGPOOL     DISK           DEVCLASS           0,0 M       0,0       0,0       90      70     

Co dalej? Dalej, to co zwykle. to jest pula typu PRIMARY, więc można ją wskazać jako destination w copygrupie.

O paru rzeczach trzeba pamiętać:

1. Pule typu DIRECTORY nie łączą się w żaden sposób z pozostałymi pulami: nie da się i backupować do copy puli, nie mają active data puli, nie można ich włączyć w hierarchię ze zwykłymi pulami. NEXT może być tylko DIRECTORY albo cloud. Edit - 23.03.2018: Windows prawda. Next musi być na zwykłą pulę i działa tylko jak ISP "mysli" że obiekt mu się nie zmieści do dirpooli.
2. Nie da się kopiować danych pomiędzy tymi pulami a zwykłymi. MOVE DATA ani MOVE NODEDATA nie zadziałają. Chyba tylko replikacja pomiędzy TSMami mogłaby pomóc. Być może export import noda, ale nie próbowałem i trwałoby to 1000 lat. Edit - 23.03.2018: Nie tysiąc tylko 3 tygodnie na dwóch łączach po 500 Mbit/s. Dla 60 TiB netto (przed deduplikacją)
3. Ochrona takich pul odbywa się wyłącznie przez replikację. Jest nowy rodzaj - replikacja miedzy pulami. Nie potrzeba drugiego TSMa. Tyle, że ta druga pula też musi być typu DIRECTORY... no albo CLOUD, ale o tym w innym wpisie. Edit - 23.03.2018: PROTECT STGPOOL do zdalnego TSMa działa jak złoto... pod warunkiem, że do puli typu Directory Container. Jak docelowa pula jest typu Cloud to qpa. Przynajmniej do wersji 8.1.4.
4. Żeby skasować taką pulę trzeba najpierw skasować kontener, a ostatnio jak to robiłem, musiało poczekać conajmniej dobę od zapisu - dlaczego? pewnie jakiś feature :-P Edit - 23.03.2018: Nasz "stary znajomy": REUSEDALAY.

Po co zatem takie pule? Przede wszystkim deduplikacja "inline" - dużo lepsza niż w przypadku "starej" deduplikacji TSM, która mocno pompowała bazę - tak x10 w stosunku do tej bez deduplikacji. A w tym wypadku nie zaobserwowałem jakiegoś szczególnego wzrostu bazy.

Drugi argument to nowa replikacja pomiędzy pulami, w tym z pulami chmurowymi (IBM SoftLayer i OpenStack Swift). Edit - 23.03.2018:Pisałem wyżej: replikacja jest na poziomie "nodów", na szczęście uwzględnia deduplikację, i jest niezależna od typów pul. Tylko jest dość wolna. A PROTECT STGPOOL do zdalnego ISP, które jest szybkie działa tylko pomiędzy pulami typu Dircontainer :-\

Trzeci argumentem, choć jeszcze go nie potwierdziłem, jest wydajność - ponoć szybciej od "starej deduplikacji" a możliwe że i może być konkurencją dla pul typu DISK. Herezja? Nie wiem, ale możliwość określenia ilości wątków zapisu do pul DIRECTORY vs jeden, sztywny wątek do DISK sugeruje, że można spróbować wycisnąć więcej z naszego wielościeżkowego storage i wielokorkowych systemów.Edit - 23.03.2018:Przynajmniej tutaj moje wcześniejsze podejrzenia się spełniły: na jedym wątku Power8 wyciąga się około 100MB/s ruchu. W P8 ma wętków 8 na korek :-P. Co ciekawe to się przekłada na jakieś 20 MB/s ruchu z dyskami, z czego ponad połowa to odczyty! Oczywiście nie przy pierszym backupie, który musi szrpnąć wszystko, ale przy incrementalach. Na intelu (jakiś Xeon z 2016 roku) prędkość przetwarzania dedupliowanych backupów wyszła na poziomie 70 MB/s na korek (nie wątek, jak w Powerach!) Czyli Power, parafrazując Twaina: Plotki o śmierci Powera okazały się grubo przesadzone.
Jeszcze jedno ciekawe spostrzerzenie po ponad dwóch latach używania dirpool: ODTWARZANIE JEST SZYBKIE. Piszę to dużymi literami, żeby miłośnicy Data Domainów tego nie przegapili :-P