Skocz do zawartości

Rekomendowane odpowiedzi

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

@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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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. 

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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ś? 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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. 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
3 godziny temu, Archi napisał:

... jeszcze samemu poprawiając co trzeba.

 

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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 :) ).

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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ł.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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 ?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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 :)

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

  • Lubię 2

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

  • Super! 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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 ? 
 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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?

  • Super! 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Podobna zawartość

    • Przez OVH
      Cześć,
       
      W tym wątku będziemy kontaktować się z Wami w celu przedstawienia informacji o wdrożeniach nowych usług, promocjach produktowych lub wydarzeniach (konferencje, szkolenia, webinary) na które będziemy chcieli Was zaprosić.
       
      Kilka słów o OVH:
       
      OVH to firma założona w 1999 roku we Francji, przez polską rodzinę Klaba. Obecnie zarządzamy 27 centrami danych w 12 lokalizacjach, na 4 kontynentach dostarczając innowacyjne rozwiązania technologiczne dla ponad 1 000 000 klientów na całym świecie. Działamy w oparciu o własną infrastrukturę, działy R&D oraz oferujemy wsparcie działu obsługi klienta 24h. W portfolio naszych usług możecie znaleźć:
       
                 Domeny: jedna z pierwszych usług, która została wprowadzona do naszej oferty. Obecnie proponujemy prawie 800 rozszerzeń do wyboru.             Hosting: proste i wydajne rozwiązanie dla osób tworzących blog, stronę WWW lub sklep internetowy.             VPS: zwirtualizowany serwer dedykowany, który stanowi kompromis pomiędzy elastycznością wirtualizacji a dowolnością konfiguracji serwera.            Serwery dedykowane: nasze maszyny umożliwiają tworzenie prostych infrastruktur jedno-serwerowych (np. w celu obsługi aplikacji) jak i zaawansowanych infrastruktur pod duże projekty.            Chmura publiczna: instancje Public Cloud to połączenie elastyczności i gwarantowanych zasobów dostępnych w przeciągu niecałej minuty.            Chmura prywatna: rozwiązanie Private Cloud oferuje skalowalność usługi Cloud na dedykowanej infrastrukturze sprzętowej. Wirtualizacja infrastruktury jest realizowana za pomocą technologii  VMware.     
                          Więcej informacji o nas i oferowanych przez nas usługach możesz znaleźć na stronie: www.ovh.pl.
      ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

       
      Na początek chcielibyśmy zaprosić Was na webinar organizowany we wtorek, 17 lipca 2018 o godzinie 11.00!
       
      Będziemy rozmawiać o  e-sporcie oraz o związanych z nim zagrożeniach. Obecnie największym wrogiem e-sportu są ataki DDoS, dlatego w trakcie prezentacji skupimy się na omówieniu tego problemu. Poddamy analizie skuteczny system anty-DDoS w kontekście infrastruktury gamingowej, najczęściej spotykane rodzaje ataków, mechanikę ich działania oraz, co najważniejsze, jak się przed nimi ochronić. Wydarzenie poprowadzą Justyna i Kuba z naszego biura we Wrocławiu. Zapisz się tutaj: https://ovh.to/U5EpVyp
      ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ OVH Sp. z. o. o.
      ul. Szkocka 5 lok. 1 - 54-402 Wrocław
      NIP: 899-25-20-556
      www.ovh.pl
    • Przez Ponury Typ
      Hej, jak w temacie. Jeśli ktoś ma zalegający serwer z tej oferty (wersja ssd) to proszę o kontakt na pw.

    • Przez motorhead
      Korzysta ktoś może z poczty w ovh?
      Znajomemu kupiłem w ovh domenę, poprosił mnie żebym podpiął pod nią jedną skrzynkę firmową i teraz mam pytanie, czy ktoś korzysta z tej darmowej poczty którą dają do domen pl?
      Chodzi mi o "start10m" - konto 10mb na stronę i 5gb na pocztę? Jak działa? Są jakieś problemy, niedochodzące meile, spam?
    • Przez sylver74
      Parametry:
      Intel  Xeon E3-1245v5 - 4/8t - 3.5GHz /3.9GHz
      RAM:  32GB DDR4 ECC 2133 MHz
      Dysk: SoftRaid 2x2 TB
      DC: WAW1
       
      Serwer w twoim panelu OVH.
       
      Możliwość wystawienia FV
      Mile widziany dłuższy okres wynajmu.
      Cena 200zł do negocjacji.

      Mail: sylver74 @ gmail.com
      Więcej informacji na PW.
    • Przez blfr
      Chciałbym wykorzystać OVH Cloud Archive do przechowywania plików, głównie backupów. Ale, mimo że bardzo OVH lubię, to nie chciałbym, żeby mi do nich zaglądali.
       
      Jakie polecacie narzędzie pod luniksa do zarządzania tymi plikami i ich szyfrowania?
       
      Najlepiej, żeby było w repo Ubuntu i FLOSS jak Stallman przykazał. Oczywiście, zaszyfrowane muszą być zarówno dane jak i indeks, nic nie powinno wyciekać. Fajnie, żeby to jakoś sensownie działało, czyli dało się pobrać pojedyncze pliki, nie było za wolne, było w miarę wygodne w obsłudze i dało się z niego korzystać na kilku maszynach. Taki Tarsnap tylko z backendem w cloudzie OVH.
       
      A w ogóle jak oceniacie tę usługę? Jakieś doświadczenia? Cena bardzo atrakcyjna. Wydaje się też rozsądna -- niewiele za samo utrzymanie, a normalnie za ruch, więc nie mają motywacji, żeby przycinać prędkości.
  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.