Jądro na serwerach OVH

[Mruczek]

Z jakiego jądra korzystacie na serwerach linuksowych w OVH?

• Ich własne, czy
• dystrybucyjne, czy
• kompilujecie któreś pod własne potrzeby?

 

Pytam, bo chciałem użyć "targetcli-fb", które wymaga TCM w jądrze. Niby nic trudnego, ale poległem na kompilacji kernela na configu z OVH, bo wymagał różnych plików z microcodem Intela, których nigdzie nie mogłem znaleźć. Cześć była w pakietach Debiana (non-free), część z paczki na stronie Intela, a o niektórych to nawet Internet nie słyszał.

 

Ostatecznie zmieniłem na jądro dystrybucji i działa.

[Matix8981]

Jeżeli centos to ELRepo najnowsze kernele wchodzą. Zazwyczaj używam już gotowych kerneli, ale jeżeli jest potrzeba to kompiluje z paczki (kernel.org)

[gb1]

@Mruczek jeśli kernel z pakietu w dystrybucji działa, to zajrzyj do "source" pakiety, popraw co tam potrzebujesz i przebuduj do własnego pakietu.

[Przemek Jagielski]

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

[SomeGuy]

2 godziny temu, Przemek Jagielski napisał:

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

 

Rozwinąłbyś? 

[Archi]

11 godzin temu, Przemek Jagielski napisał:

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

 

I to jest bardzo dobre podejście. Sam tak robię, choć teraz preferuję robić 3-way-merge configa distro i configa OVH, jeszcze samemu poprawiając co trzeba.

[Poziomecki]

Z ciekawości. Jakie problemy / błędy mieliście z jądrem od OVH?

[Przemek Jagielski]

11 godzin temu, SomeGuy napisał:

 

Rozwinąłbyś? 

Spróbujmy. 

Osobiście robię to trochę na około, bo ręcznie (a pewnie da się to szybciej, @Archi liczę tu na jakąś wskazówkę). W jednej konsoli mam odpalony konfig na maszynie działającej a na maszynie, którą robię, klikam co mam klikać. Wymianę kernela robię głównie co rilis, chyba, że w changelogu coś wyhacze ważniejszego (chociaż ostatnio z czytaniem changelogów jestem w plecy). Ale jak robię wymianę rilisu to już mam gotowy config. 

3 godziny temu, Archi napisał:

 

I to jest bardzo dobre podejście. Sam tak robię, choć teraz preferuję robić 3-way-merge configa distro i configa OVH, jeszcze samemu poprawiając co trzeba.

A jak to robisz? Mógłbyś coś więcej powiedzieć? 

3 minuty temu, Poziomecki napisał:

Z ciekawości. Jakie problemy / błędy mieliście z jądrem od OVH?

Ostatnio się zaskoczyłem, kiedy trzeba było wgrać intel-microcode, gdzie tylko w OVH trafiłem na to. 

[gb1]

3 godziny temu, Archi napisał:

... jeszcze samemu poprawiając co trzeba.

 

Ponownie z ciekawości zapytam, co tam zwykle uważasz że trzeba poprawiać ?

[Archi]

4 godziny temu, gb1 napisał:

 

Ponownie z ciekawości zapytam, co tam zwykle uważasz że trzeba poprawiać ?

 

Zależy od przeznaczenia serwera. Politykę ASPM na performance, cpu governor na performance, I/O scheduler w zależności czy mam system na hdd czy ssd cfq lub noop, kernel patchuję patchem od graysky2 żeby mu wrzucić -march=native,  przerwania CPU ustawiam na ogół na 250 MHz, do tego wyłączam wszystkie zbędne funkcje, żeby się w ogóle nie budowały, cały debug, czy nawet takie rzeczy jak support procesorów AMD (no bo po co jak mam intela).

 

Ogółem dużo rzeczy można pozmieniać. To wyżej to tylko to co mi do głowy przyszło.

 

5 godzin temu, Przemek Jagielski napisał:

Osobiście robię to trochę na około, bo ręcznie (a pewnie da się to szybciej, @Archi liczę tu na jakąś wskazówkę).

 

Diffmerge, zwykły diff, make localmodconfig czy diff oryg configa z configiem OVH i zaaplikowanie na nowy, po czym make oldconfig. Też dużo możliwości.

[patrys]

Na wielu serwerach działa jądro kompilowane przez OVH i nie ma żadnych problemów.

Wiadomo tak jak pisał @Archi nie jest ono jakoś specjalnie optymalizowane ale działa poprawnie przy większości zastosowań.

Tak naprawdę nie ma większych różnic między dystrybucyjnym jądrem, a tym od OVH.

Wydajnościowo będzie podobnie, jedynie jądra OVH mają dodane patche pod ich sprzęt i z reguły są nowsze niż te dystrybucyjne ( no chyba, że używamy Archa ).

[Mruczek]

Ja właśnie chciałem zachować to dopasowanie pod ich sprzęt (zwłaszcza, że to serwerek na DN2800MT), ale dokompliować wsparcie dla TCM (Target iSCSI). Ale poległem na dodatkowych mirocode'ach, które w configu są dodane jako "linki" do binarek Intela. Pakiet Debiana miał ich część, część była w paczce od Intela, ale ponad 4 nie mogłem za Chiny namierzyć. Niby mogłem ograniczyć się do firmware'u dla mojego procka, ale wybrałem linię najmniejszego oporu (oryginalne jądro Debiana, z TCM już w module).

 

Nota bene, fajnie chodzi iSCSI między dwoma serwerami w OVH. Kimsufi jako dysk dla VPSa z Windowsem :-) Oczywiście bardziej jako PoC lub do użytku prywatnego. Firmy, czy klientów tak bym nie postawił.

[gb1]

W dniu 15/02/2018 o 18:30, Archi napisał:

Ogółem dużo rzeczy można pozmieniać. To wyżej to tylko to co mi do głowy przyszło.

 

Większość opcji jest konfigurowalnych zwykle. Większość z wymienionych opcji może być konfigurowalna nie na etapie kompilacji, zatem ponownie z ciekawości zapytam czy widzisz jakieś rozsądne uzasadnienie aby robić to na etapie kompilacji jądra ?

 

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

[Archi]

2 godziny temu, gb1 napisał:

 

Większość opcji jest konfigurowalnych zwykle. Większość z wymienionych opcji może być konfigurowalna nie na etapie kompilacji, zatem ponownie z ciekawości zapytam czy widzisz jakieś rozsądne uzasadnienie aby robić to na etapie kompilacji jądra ?

 

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

 

Większość tego co wymieniłem tak, większość tego co wywalam z kompilacji, żeby się w ogóle nie budowało wraz z ich zależnościami już nie, a przecież nie będę Ci wymieniał każdego pojedynczego drivera.

 

2 godziny temu, gb1 napisał:

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

 

Ja mam raczej autorskie rozwiązanie oparte hybrydowo na pakietach budowanych ze źródeł i paczkach deb z repo. Mam określoną konfigurację każdego pakietu - serwer testowy każdego dnia dokonuje self-update'a (w pełni automatycznie), wraz z rebootem. Po reboocie lecą unit testy na wszystko co kiedykolwiek mnie zawiodło czy nie ma żadnych regresji (począwszy od tego czy serwis X wstaje, poprzez to czy wspiera funkcjonalność X, a na benchmarku raw wydajności i testach obciążeniowych kończąc). Jeśli wszystkie testy przejdą bez problemu to leci automatyczny deploy na wszystkie maszyny w tej samej konfiguracji. Pakiety ze źródeł są budowane tam gdzie dorzucam łatki -march=native, czyli praktycznie wszędzie gdzie coś grzebię (aktualnie kernel, .net core runtime, nginx, php-fpm i mariadb).

 

Wszystkie maszyny jadą na debianie testingu na produkcji

[Przemek Jagielski]

@Archi a dokompilowywałeś Live Patch czy nie jesteś zwolennikiem tego rozwiązania? 

[Archi]

1 godzinę temu, Przemek Jagielski napisał:

@Archi a dokompilowywałeś Live Patch czy nie jesteś zwolennikiem tego rozwiązania? 

 

Nie, reboota potrzebuje również z innych względów (np. żeby sprawdzić czy usługi dobrze wstają, systemd działa poprawnie itp.) więc nie jest mi to do niczego potrzebne.

[blfr]

Dystrybucyjny kernel, jeśli tylko się da. Coś innego tylko jeśli absolutnie muszę, ale ostatnio rzadko muszę.

[gb1]

W dniu 17/02/2018 o 17:18, Archi napisał:

większość tego co wywalam z kompilacji, żeby się w ogóle nie budowało wraz z ich zależnościami już nie

 

Jaki masz cel że to wywalasz ? Jakieś konkretne kwestie wydajnościowe ? bezpieczeństwa ? jakieś inne ?

 

W dniu 17/02/2018 o 17:18, Archi napisał:

Po reboocie lecą unit testy...

Testy w bashu ? Z czegoś ciekawego korzystasz do testów ? Stale poszukujemy dobrego rozwiązania do testów w bashu jednak pomimo korzystania z wielu żaden nie przypadł nam do gustu, choć najczęściej korzystamy z BATS choć nie rozwijany i siermiężny.

 

W dniu 15/02/2018 o 18:30, Archi napisał:

kernel patchuję patchem od graysky2 żeby mu wrzucić -march=native

 

Dokonywałeś jakiś testów wydajnościowych w tym zakresie ? Jeśli tak to w jakim obszarze lub obciążeniach uzyskujesz największy przyrost wydajności w stosunku do standardowych kerneli z dystrybucji ? 

W zeszłym roku dokonaliśmy takich testów i przyznam, że przy większości obciążeń brak było popraw wydajności powyżej kilku niskich procent. Wcześniej także dokonywaliśmy podobnych testów korzystając z kompilatora Intela, tam także nie było znacznie lepiej. 

 

(powyższe dotyczy kompliowania kernela w opisany sposób)

 

Podobnie w przypadku kompilacji aplikacji/usług, czy testowałeś zyski na wydajności ? Tutaj znaczący uzysk widzieliśmy przy szyfrowaniu (np. w przypadku https), ale to zrozumiałe. 

 

W dniu 18/02/2018 o 12:31, Przemek Jagielski napisał:

a dokompilowywałeś Live Patch czy nie jesteś zwolennikiem tego rozwiązania?

 

IMHO dużo zależy od kontekstu, czyli jaki miałby być cel wykorzystania Live Patcha ? 
 

[Pół człowiek pół admin]

W dniu 2/19/2018 o 15:55, blfr napisał:

Dystrybucyjny kernel, jeśli tylko się da. Coś innego tylko jeśli absolutnie muszę, ale ostatnio rzadko muszę.

 

To najsensowniejsze IMHO podejście, jeśli nie hostuje się na ovh jakiegoś Netflixa, czy czegoś w ten deseń, albo użycie jakiegoś mechanizmu tego wymaga.

[Spoofy]

Tam gdzie się da - pcham swoje jajko z masą patch'y i w innych konfiguracjach.

[Pół człowiek pół admin]

3 godziny temu, Spoofy napisał:

Tam gdzie się da - pcham swoje jajko z masą patch'y i w innych konfiguracjach.

Co cię motywuje do tego? Przeprowadzasz regularnie testy na podatności własnego tworu?

[Przemek Jagielski]

A wracając do jąder w OVH - ostatnio natrafiłem na dziwny problem, ponieważ na VPSach i Public Cloudach, nie chce wstać sieć. Wywala błąd, mówiący o tym, że nie może połączyć się z 169.254.169.254. W momencie, kiedy wracam do standardowego jądra, z dystrybucji, problem ustępuje. Jakie konkretne moduły OVH potrzebuje do działania sieci, oprócz obsługi DHCP i 8021q? 

[patrys]

Nie lepiej przestawić dhcp na statykę ?

[Przemek Jagielski]

Właśnie OVH mi samo to zaproponowało - o dziwo działa. Łamiący jest fakt, że konsultant nie jest w stanie powiedzieć, jak jest skonfigurowana usługa, bądź nie jest w stanie powiedzieć, jaki moduł odpowiada za prawidłowe działanie. @OVH, możecie coś na ten temat powiedzieć? 

[patrys]

Pomijając już moduły, to ostatnio były faile z DHCP.

Więc w sumie robiąc statykę i wyłączając w cloud-init ustawienia sieci eliminujesz potencjalną usterkę.