RSS Feed

Posts Tagged ‘vserver’

  1. Linux-vserver, hit the barrier, reiserfs i jak to naprawić

    Sierpień 10, 2012 by 0verlord

    Linux-vserver zanim został uznany za przestarzały i zastąpiony containerami lxc był całkiem sensownym odpowiednikiem BSDowych jaili.
    W ostatnich wersjach z loopbackiem jest już całkiem używalny i pozwala na sensowną separację i zarządzanie zasobami dla rozmaitych usług.

    Tego posta piszę bardziej jako przypominajkę dla każdego, kto trafi na problem z filesystemem wewnątrz guesta, który objawia się losowymi problemami z dostępem, znikającymi plikami i urządzeniami i ogólnymi randomami w środku vservera.

    U mnie problemem okazała się interakcja reiserfsa i vservera. Kilka razy na dobę odlatywały różne części różnych guestów i ogólnie działy się złe rzeczy.

    Przyczyny i rozwiązania należy szukać na hoście. Dmesg najczęściej w takich przypadkach pokazywał, że plik, który akurat zniknął na gueście, jak to malowniczo określił mój kolega: „hitnął w barierkę”. Kawałek loga może wyglądać np. tak:

    [2053443.951267] vxW: [?ps?,12778:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.
    [2053445.370697] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d050980[#0,5] ?/dev/pts/2?.
    [2053445.370706] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d050980[#0,5] ?/dev/pts/2?.
    [2053445.371055] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.
    [2053445.371062] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.

    albo tak:

    808950.409850] vxW: [?ruby?,25311:#40052|40052|40052] did hit the barrier.
    [808950.409856] vxW: [?ruby?,25311:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808950.410268] vxW: [?ruby?,25311:#40052|40052|40052] did hit the barrier.
    [808950.410271] vxW: [?ruby?,25311:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808962.531726] vxW: [?ruby?,25807:#40052|40052|40052] did hit the barrier.
    [808962.531731] vxW: [?ruby?,25807:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808962.532145] vxW: [?ruby?,25807:#40052|40052|40052] did hit the barrier.
    [808962.532148] vxW: [?ruby?,25807:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.

    W tym drugim przypadku kilka gemów przestało działać, wysadzając z ten sposób jedną z aplikacji railsowych. Poziom randomów powodował, że ilość hitów w google z błędami często spadała poniżej 1 (słownie: jednego) wyniku.

    Jak się okazało, jeżeli ma się reiserfsa, należy partycję, na której znajdują się fizycznie guesty zamontować z parametrem user_xattr. Tak to wygląda w moim fstabie:

    /dev/md5 /home reiserfs rw,user_xattr 0 0

    Dodajemy parametr w fstabie, wykonujemy mroczne zaklęcie:

    mount -o remount,rw,user_xattr /home

    (jeżeli nie pomoże, to rebootujemy hosta) i cieszymy się światem bez barrier ;-). A jak już nas spotka hit w barierę, to wykonujemy kolejne polecenie, które usuwa barierę.

    setattr -R --~barrier katalog/na/mainie

    A ogólnie,bariera to taki mechanizm niepozwalający na ucieczkę z guesta do innych zasobów. Można o tym dokładniej poczytać tu.


  2. Wiele vserverów i problem ramu

    Wrzesień 19, 2011 by 0verlord

    Obiliśmy się tutaj o dość interesujący problem z vserverami. Co to są linux-vservery, można przeczytać tutaj.

    Mamy hosta, na którym stoi kilkanaście vserwerów. Każdy konfigurowany wg odrobinę przerobionego skryptu instalacyjnego, a konkretnie poszerzający /tmp do 512m. Dlaczego więcej, można np. przeczytać tu.

    Problem jest taki, że /tmp w domyślnej konfiguracji jest montowany wewnątrz vservera tak:
    none /tmp tmpfs size=512m,mode=1777 0 0

    Czyli katalog /tmp to jest tak na prawdę tmpfs, czyli tak na prawdę ram. 500 mega ramu w sumie marnujące się dość bez sensu. Jeżeli nie potrzebujemy jakiegoś specjalnie wydajnego guesta, można spokojnie zrezygnować z takiego rozwiązania kwestii /tmp’a.

    Co ma się gdzie montować, w vserverze jest zaszyte w fstabie, który z kolei siedzi w katalogu głównym z konfiguracją guestów, w Debianie tu:
    /etc/vservers/NazwaVservera/fstab

    Usuwamy linijkę z tmpfs i restartujemy vserver. Po tej operacji, vserver zacznie swoje pliki tymczasowe zapisywać normalnie w filesystemie, zwalniając ram. Mission accomplished, ram odzyskany, tadam.wav. U nas zwolniło się w ten sposób 3GB.


  3. Backupninja 0.9.8, backup mysqla w vserverze i bug

    Kwiecień 27, 2011 by 0verlord

    Objawia się tak: mamy sobie głównego hosta, i kilka guestów (vserverów). Na jednym z nich chodzi mysql. Dodajemy akcję do backupninja przy pomocy helpera, żeby nam robił dumpa wszystkich baz. Konfiguracja z ninjahelperem jest banalna, więc ją pominę. Error w debugu wygląda np. tak dla losowej bazy:
    Debug: su root -c "/usr/sbin/vserver mysql exec /usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names sugarcrm -r '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql'"
    Warning: mysqldump: Can't create/write to file '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql' (Errcode: 2)
    Warning: Failed to dump mysql databases sugarcrm

    Teraz ocb? Skrypt wykonujący backup, konkretnie ten (na Debianie):
    /usr/share/backupninja/mysql
    wydaje się nie zauważać, że wykonuje polecenie w środku vservera, więc nie ma tam katalogu podanego jako parametr do polecenia. To co widać powyżej, szuka katalogu
    /home/vservers/mysql/var/backups/mysql/sqldump
    ale w środku vservera, czyli jak byśmy zrobili na gueście katalog taki:
    /home/vservers/mysql/var/backups/mysql/sqldump
    widziany z poziomu maina jako
    /home/vservers/home/vservers/mysql/var/backups/mysql/sqldump
    to by się backup zrobił, ale szukać by go trzeba gdzie indziej.

    Jak to naprawić? Generalnie bez zagłębiania się w logikę kodu, i zdając sobie sprawę, że mogę popsuć coś innego, hackujemy sobie na szybko
    /usr/share/backupninja/mysql,
    linijka 287 i okolice.

    # Test to make sure mysqld is running, if it is not sqldump will not work
    $VSERVER $vsname exec su $user -c "$MYSQLADMIN $defaultsfile ping 2>&1 >/dev/null"
    if [ $? -ne 0 ]; then
    fatal "mysqld doesn't appear to be running!"
    fi
    if [ "$compress" == "yes" ]; then
    execstr="$VSERVER $vsname exec $DUMP | $GZIP $GZIP_OPTS > '$vroot$dumpdir/${db}.sql.gz'"
    else
    execstr="$VSERVER $vsname exec $DUMP -r '$vroot$dumpdir/${db}.sql'"
    fi
    else

    usuwamy ‚$vroot’ z linijek zaczynających się na execstr, i zostaje samo ‚$dumpdir’. czyli tutaj ‚/var/backups/mysql/sqldump’ czyli tak, jak ma być.
    I to wszystko. W ten sposób usuwamy /home/vservers z argumentu do vserver exec i już polecenie widzi odpowiedni katalog.

    Ciekawe, że nikt tego nie znalazł do tej pory, bo buga poprawiam drugi raz, pierwszy raz trafiłem go w Lenny’m i się pojawił po upgrade do Squeeze’a.