Archiv rubriky: Solaris

Jak v Solaris / SmartOS zjistit sériové číslo diskového řadiče

V Solarisu se na to hodí nástroj prtpicl. Ten však zobrazí poměrně hodně textu. Je proto lepší si jej omezit např. programem egrep na výrobce vašeho řadiče takto:

prtpicl -v | egrep -i "lsi|sas"

Tento nástroj se také dá využít na zjištění informací prakticky o všem, co v systému je dostupné.

Zdroj: https://www.thegeekdiary.com/how-to-identify-the-hba-cardsports-and-wwn-in-solaris/

SmartOS, route a IP adresy od OVH

Mám nyní u skvělého dodavatele serverů OVH jeden server, na kterém jsem chtěl vytvořit několik VPS. Nechal jsem si k serveru přidělit dodatečné IP adresy, ale ouha, po konfiguraci zóna nemá síť. Jak z toho ven?

Problém je v tom, že brána pro dodatečné IP je v jiném subnetu než přidělené IP adresy. Musíme tedy zóně nejprve dát vědět, kudy se do toho subnetu dostane. To provedeme spuštěním následujícího příkazu uvnitř VPS:

route -p add XXX.XXX.XXX.0/24 YYY.YYY.YYY.YYY -interface -ifp net0

XXX.XXX.XXX jsou první 3 octety IP adresy global zóny (fyzického serveru). YYY.YYY.YYY.YYY je dodatečná IP, nastavená VPS serveru.

Protože VPS při startu bránu nenašel, bude potřeba ručně přidat ještě tu:

route -p add default XXX.XXX.XXX.254

XXX.XXX.XXX jsou opět první 3 octety IP adresy global zóny. OVH jako bránu používá vždy poslední adresu z daného rozsahu, tedy 254.

Parametr -p (persist) v příkazech říká, že se má nastavení uložit. Nesmaže se vám tedy po restartu serveru.

Samotné nastavení se ukládá do souboru /etc/inet/static_routes

Ekvivalent pro Linux (Ubuntu):

route add -net XXX.XXX.XXX.0/24 gw YYY.YYY.YYY.YYY dev eth0
route add default gw XXX.XXX.XXX.254

SmartOS, PuTTY a klávesy HOME, END a DEL

Pokud vás také zdržuje, že ve SmartOS nefungují na konzoli klávesy HOME, END a DELETE, zde je způsob, jak to napravit.

V domovském adresáři vytvoříme soubor .inputrc s následujícím obsahem:

"\e[3~": delete-char
"\e[1~": beginning-of-line
"\e[4~": end-of-line

Díky tomuto souboru bude bash vědět, jakou funkci má pro dané klávesy použít. Změny se projeví až po opětovném přihlášení.

Co ale dělat v případě globální zóny, kdy se tento soubor po restartu ztratí? Vytvoříme si pro něj SMF službu!

Nejprve soubor .inputrc nakopírujte do adresáře /opt/custom. Pokud tento adresář nemáte vytvořen, tak jej vytvořte.

Poté vytvořte soubor /opt/custom/smf/inputrc_link.xml s následujícím obsahem:




    
        
        
        
            
        
        
            
        
        
        
        
        
            
            
        
        
        
        
    

SmartOS po restartu automaticky načítá XML soubory z tohoto adresáře, službu nám naimportuje a vyrobí link.

Malý tip na závěr: Ve SmartOS zónách je stejný problém, ačkoliv stačí jen nakopírovat soubor .inputrc do adresáře uživatele, není potřeba SMF služba. Dělat to pro každou zónu je ale otrava. Můžeme si to zjednudušit tím, že soubor nakopírujeme do šablony zóny stáhnuté přes imgadm. Např. takto pro uživatele root:

cp /root/.inputrc /zones//root/root/

Solaris (SmartOS) TCP tuning, nginx a chyba phantom event for closed and removed socket

Nedávno se mi v error logu nginxu objevila řada následujících chyb:

2013/09/14 21:05:01 [alert] 26115#0: phantom event 0001 for closed and removed socket 21
2013/09/29 08:52:59 [alert] 49045#0: phantom event 0004 for closed and removed socket 17
2013/09/30 16:51:37 [alert] 49045#0: phantom event 0001 for closed and removed socket 46
2013/10/09 11:01:15 [alert] 92940#0: phantom event 0004 for closed and removed socket 28

Samozřejmě jsem nejprve Googloval a v prvních pár dotazech našel odpověď. Mám ale ve zvyku nejprve pochopit, co vlastně tomu serveru cpu do konfigurace a proč to vyřešit právě takto a ne jinak. Zkoumal jsem tedy dál a snad i pochopil, v čem je vlastně jádro problému.

Proč vlastně tento problém vzniká?

  • Nginx je asynchronní server. Veškeré operace zpracovává během iterací tzv. event loop-u (také nazývaného IO loop).
  • Solaris nginxu předává eventy (připojení klientů) tzv. poll-em pomocí zařízení /dev/poll.
  • Chyba vzniká nekonzistencí při práci nginxu s /dev/poll, který vrací eventy hromadně v jedné iteraci.
  • Výchozí limit eventů předaných kernelem nginxu je pro /dev/poll nastaven na 32.
  • Nginx při práci s jednotlivými eventy otevírá jejich sockety postupně. Když chce zpracovat další, musí současný socket zavřít. Pokud tedy kernel předá nginxu až 32 eventů (spojení s klienty), při větším vytížení serveru se může stát, že event již není aktivní (klient se odpojil).
  • Dá se to vyřešit tím, že nginx donutíme přijímat od kernelu vždy jen jeden event během iterace. V confu to nastavíme parametrem devpoll_events.
  • Na výkonu nginxu by se to mělo projevit jen neznatelně.
events {
    devpoll_events 1;
}

Jaký je skutečný důvod vzniku problému?

Ačkoliv tímto nastavením zařídíme, aby si už nginx nestěžoval do logu, příslovečný pes je zakopaný někde jinde. Kernel má totiž limity pro maximální počet navázaných a příchozích spojení, které jsou v základu poměrně malé. Pokud server obdrží nový požadavek na spojení, který se nevejde do bufferu, starší spojení se zahodí.

Parametry tcp_conn_req_max_q a tcp_conn_req_max_q0

Parametry tcp_conn_req_max_q a tcp_conn_req_max_q0 určují maximální počet požadavků, které mohou být přijmuty na jednu IP adresu a jeden port. tcp_conn_req_max_q je maximální počet příchozích spojení, které mohou být akceptovány (accepted) na IP a port. tcp_conn_req_max_q0 je maximální počet „polovičně otevřených“ (half-open) TCP spojení, které mohou existovat na portu. Parametry jsou odděleny kvůli efektivnímu blokování SYN segment denial of service útoků.

Jak zjistit, zda byly limity překročeny?

netstat -s|grep ListenDrop
  • Pokud je tcpListenDrop nenulový, je potřeba navýšit tcp_conn_req_max_q.
  • Pokud je tcpListenDropQ0 nenulový, je potřeba navýšit tcp_conn_req_max_q0.

Ale počkat! Není to zase tak úplně jednoduché. Navýšením tcp_conn_req_max_q na příliš vysoké hodnoty můžeme otevřít cestu pro SYN segment denial of service útoky. Solaris to má ale díky oddělení parametrů dobře vymyšleno. Navyšujte tcp_conn_req_max_q v násobcích 256. Použijte tcp_conn_req_max_q0 pro zvýšení počtu „polovičně otevřených“ TCP spojení. Pokud nginx nebo jiný server nemůže zpracovávat spojení dostatečně rychle, zvýšení tcp_conn_req_max_q0 může zabránit tomu, že se klienti nebudou schopni připojit. Spojení klientů zůstávají v „polovičně otevřeném“ stavu, dokud je nginx nezpracuje.

Jak limity nastavit?

ndd -set /dev/tcp tcp_conn_req_max_q 4096
ndd -set /dev/tcp tcp_conn_req_max_q0 8192

Pozor! Po nastavení limitu je potřeba restartovat nginx nebo jiné aplikace, kterých se to týká! Také tato nastavení se vyresetují restartem systému. Jak je nastavit permanentně si řekneme ale až v příštím článku 🙂

Zdroje

Jak ve SmartOS zóně založené na image base64 rozchodit Sphinx search

Rozchodit Sphinx daemon ve SmartOS zóně chce trochu snahy navíc. Hned po instalaci nefunguje.

Sphinx by měl být v zóně vytvořené z image base64 (alespoň od verze 13.1.0) již předinstalovaný. Ověřit si to můžeme pomocí pkgin:

# pkgin se sphinxsearch
sphinxsearch-2.0.8 = Sphinx Full-Text Search Engine

Následně jej aktivujeme pomocí svcadm:

svcadm enable sphinx

V tuto chvíli Vám ale fungovat nebude:

# svcs -a|grep sphinx
maintenance    15:25:22 svc:/pkgsrc/sphinx:default

Zobrazíme si tedy log SVC:

# tail /var/svc/log/pkgsrc-sphinx\:default.log
[ Aug 28 15:18:00 Enabled. ]
[ Aug 28 15:18:00 Could not interpret "user" property value "pbulk", error 2. ]

Vypadá to, že v systému nemáme uživatele pbulk. Ale zakládat jej nebudeme, pro sphinx už totiž uživatel připraven je:

# cat /etc/passwd|grep sphinx
sphinx:x:1001:1001:sphinxsearch sphinx user:/nonexistent:/usr/bin/false

Nastavíme tedy SVC, aby daného uživatele použilo:

# svccfg -s pkgsrc/sphinx setprop method_context/user=astring: sphinx
# svccfg -s pkgsrc/sphinx setprop method_context/group=astring: sphinx
# svcadm refresh sphinx
# svcadm clear sphinx

Sphinx ale stále neběží, máme tu ještě jeden problém:

# tail /var/svc/log/pkgsrc-sphinx\:default.log
[ Aug 28 15:24:08 Leaving maintenance because clear requested. ]
[ Aug 28 15:24:08 Enabled. ]
[ Aug 28 15:24:08 Executing start method ("/opt/local/bin/searchd -c /opt/local/etc/sphinx.conf"). ]
[ Aug 28 15:24:08 svc.startd could not set context for method:  ]
[ Aug 28 15:24:08 chdir: No such file or directory ("/nonexistent") ]
[ Aug 28 15:24:08 Method "start" exited with status 96. ]

Vypadá to, že složka, ve které má uživatel sphinx svůj home, neexistuje. Změníme ji na existující:

# usermod -d /var/spool/sphinx sphinx

Nyní už by nám měl Sphinx vpořádku naběhnout. Pokud tedy máme správně nastaven conf a vygenerované indexy.

# svcadm clear sphinx
# svcs -a|grep sphinx
online         15:25:22 svc:/pkgsrc/sphinx:default

Když vám v solarisu nejde pod uživatelem nastavit cron nebo se klíčem přihlásit na SSH

Nedávno jsem potřeboval vytvořit v Soalrisu uživatele pro weby a nastavit mu nějaké crony. To se provede takto:

contab -e uzivatel

Pravděpodobně se vám ale stane, že dostanete chybu:

Warning - Invalid account: 'uzivatel' not allowed to execute cronjobs

Cron sice půjde uložit, ale nebude fungovat. Po chvíli beznaděje jsem problém objevil v souboru /etc/shadow. Solaris jej má oproti Linuxu trochu jiný:

uzivatel:*LK*:::::::

Důležité je ono *LK*, to totiž znamená, že je uživatel locked, nemůže tedy spouštět ani cronjoby. Stačí onen záznam změnit na NP, což znamená no password.

uzivatel:NP:::::::

Instalace (migrace) SmartOS na RAIDZ2

RADZ2 je alternativa Linux RAID6. Na checksum jsou tedy použity dva disky. Nejmenší počet disků, pro které lze tuto konfiguraci použít jsou 4. V takovém případě ale počítejte s tím, že pole bude mít jen poloviční kapacitu součtu kapacit disků.

Další problém pouze 4 disků (pokud ke stroji nemůžete dočasně připojit další) je ten, že SmartOS při instalaci RAIDZ2 pole vytvořit neumí. A když systém nainstalujete jen na jeden disk, ze zbylých 3 disků RAIDZ2 pole nevytvoříte. Jeden disk vám bude chybět. Jak tento nedostatek obejít?

Začneme instalací. Nejprve si systém nainstalujeme pouze na jeden disk.

c0t0d0

Když máme instalaci hotovou, nabootujeme SmartOS bez importu zfs poolů.

Live 64-bit (noinstall)

Importujeme pool zones pod názvem zones2

zpool import zones zones2

Odmountujeme dataset zones2/cores.

umount zones2/cores

Smažeme složku /zones, aby nepřekážela až budeme vytvářet pool zones.

rm -r /zones

Zjistíme, kolik zabírá celý pool zones2.

zfs list

Vytvoříme pomocí dd prázný sparse soubor větší než velikost poolu zones2.

dd if=/dev/zero of=/disk.img bs=1 seek=40G count=1

Vytvoříme RADZ2 pole ze zbylých 3 disků a soubor z předešlého kroku použijeme jaho čtvrtý disk. Parametr -f je nutný aby příkaz zpool neřval kvůli rozdílným velikostem disků a že mixujeme jednotky a soubory.

zpool create -f zones raidz2 /disk.img c0t1d0 c0t2d0 c0t3d0

Soubor použitý u poolu jako jeden z disků převedeme do offline stavu. Tento krok je důležitý. Bez něj by při přenášení dat mezi pooly došlo na SmartOS ramdisku místo.

zpool offline zones /disk.img

Volitelně můžeme před přenosem zapnout kompresi disku. Soubory se nám pak během přenosu budou ukládat zkomprimované.

zfs set compression=gzip-9 zones2

Vytvoříme rekurzivní snapshot poolu zones2.

zfs snapshot -r zones2@current

Přemigrujeme data z poolu zones2 do zones. Přepínač -R u zfs send říká, že pošleme rekurzivně i podřízené datasety. Přepínač -p posílá i properties datasetů (např. nastavenou kompresi). Přepínač -F u zfs recv zajistí, že se v cílovém poolu promaže vše, co tam nemá být.

zfs send -Rp zones2@current|zfs recv -F zones

Smažeme snapshot current v cílovém poolu

zfs destroy -r zones@current

Pokud vše proběhlo v pořádku, můžeme nyní zrušit pool zones2

zpool destroy zones2

Nahradíme soubor použitý při vytváření poolu zones diskem, který se nám nyní uvolnil

zpool replace zones /disk.img c0t0d0

Po chvíli máme data sesynchronizována a pool zones už jede na plnohodnotném RAIDZ2 poli.

zpool status

Nyní je ještě potřeba pool rozšířit na celou kapacitu disků.

zpool set autoexpand=on zones

Projistotu provedeme export poolu.

zpool export zones

A uděláme reboot. Po najetí SmartOS s importem poolů vše pojede z právě vytvořeného RAIDZ2 pole. Enjoy!

Test rychlosti ZFS s kompresí a ZIL

Nějakou dobu se mi doma povalují disky ze starších serverů, povětšinou SAS 73GB 15k RPM. Pro tyhle disky už v dnešní době nemám moc využití, do serverů jsou prostě malé. Chtěl jsem ale vyzkoušet, zda by mohly efektivně sloužit alespoň jako ZIL u ZFS a být mi tak k něčemu dobré.

Testy jsem prováděl na náledujícím stroji s nainstalovaným SmartOS

Fujitsu-Siemens Primergy RX300 S3 D2119
2x Quad-core Xeon (bez HT, konkrétní typ ještě doplním)
12 Gb DDR2 FBDIMM
2x Fujitsu 146GB 10k RPM MAX3147RC (zpool)
2x Seagate 73GB 15k RPM ST373455SS (ZIL)

První sada testů probíhala nad mirrorem ze 146GB disků bez ZILu:

pool: zones
 state: ONLINE
  scan: resilvered 4.00G in 0h0m with 0 errors on Sun Feb 24 21:56:41 2013
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t0d0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0

errors: No known data errors

Druhá sada testů probíhala nad stejným poolem s přidaným mirrorem ze 73GB disků jako ZILem:

pool: zones
 state: ONLINE
  scan: resilvered 4.00G in 0h0m with 0 errors on Sun Feb 24 21:56:41 2013
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t0d0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            c0t3d0  ONLINE       0     0     0
            c0t4d0  ONLINE       0     0     0

errors: No known data errors

První test v každé sadě probíhal s vypnutou kompresí:

zfs set compression=off zones

Druhý test v každé sadě probíhal se zapnutou kompresí GZIP na nejvyšší level:

zfs set compression=gzip-9 zones

Testoval jsem pomocí bonnie++ s následujícím nastavením:

bonnie++ -d /zones/bonnie -u 0 -n 256

Pro snadnější porovnání výsledků jsem sestavil přehlednou tabulku:

ZFS ZIL compression test results

Co si z toho všeho vyvodit?

  • Použít 15k RPM SAS jako ZIL pro 10k RPM SAS nemá cenu. Možná by výledky byly lepší, kdyby byl pool ze 7200 RPM SATA disků, ale pochybuju o tom. Možná by byly lepší, kdyby bylo více konkurentních zápisu, ale dělat další testy se mi už nechce.
  • To že komprese disku zrychluje jsem věděl už předtím, ale že je to o tolik, to jsem opravdu netušil. Ačkoliv z raw výsledků je patrný slušný nárůst využití CPU, komprimovat pool se jednoznačně vyplatí.
  • Pro někoho může být matoucí, že se komprimovaná data čtou a zapisují rychleji, než data nekomprimovaná. Je to z toho důvodu, že disk díky kompresi musí provést méně seeků, ať už při čtení nebo zápisu. Na dnešních CPU je overhead komprese opravdu malý, výkon serveru jako celku to tedy ovlivní spíše pozitivně.
  • Pozor na některá SSD, která by jste chtěli použít pro pool. Často si data komprimují samy, aby méně opotřebovávaly paměťové čipy. V takovém případě je komprese na poolu spíše kontraproduktivní.

ZIL: off, komprese: off

Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test            24G 69331  58 68951  14 26294   7 47317  45 55544   6  1362   5
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 13680  97 43499  68 10799  49 17940  97 42623  67 24912  98

ZIL: off, komprese: gzip-9

Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test            24G 118003 99 270385 56 104136 29 73052  69 197714 20  9246  40
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 14627  99 62096  99 26730  99 17557  99 73472  99 25722  99

ZIL: on, komprese: off

Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test            24G 69493  59 67928  14 26515   7 47986  46 55534   6 908.3   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 16239  99 42565  98 26451  99 17479  99 72271  99 25860  99

ZIL: on, komprese: off

Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test            24G 117788 99 272982 57 105002 30 73069  69 197627 20 10390  41
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 14035  98 69112  99 26849  99 18608  99 65876  93 25567  99

Jak zprovoznit htop ve SmartOS global zóně

Docela jsem si zvykl na htop a ačkoliv ve SmartOS zónách funguje, v globální zóně tomu tak není. Pro svůj chod htop potřebuje linuxový /proc filesystém, který v globální zóně není. S trochou snahy jej ale můžeme dodat.

Pokud jste ještě do globální zóny nenainstalovali pkgin, je právě čas. Návod najdete na wiki smartosu. Samotný htop pak snadno nainstalujeme pomocí příkazu:

pkgin in htop

Nyní vytvoříme shell shkript, který nám namountuje lxproc a umístíme jej do souboru /opt/custom/method/fs-lxproc.

#!/sbin/sh

. /lib/svc/share/smf_include.sh

if smf_is_globalzone; then
    mkdir /system/lxproc
    mount -F lxproc lxproc /system/lxproc
fi

exit $SMF_EXIT_OK

Adresář /op/custom a jeho podadresáře ještě pravděpodobně vytvořeny nemáte, založte je tedy. Budeme pokračovat vytvořením XML definice pro SMF, aby se náš mount skript spouštěl automaticky. Skript uložíme do souboru /opt/custom/smf/lxproc-fs.xml. Do tohoto adresáře lze uložit i jiné definice SMF služeb, SmartOS je při bootu načte a spustí.



    

        
        

        
            
        

        
        

        
            
        

        

        
    

Nakonec XML definici načteme do SMF.

svccfg import /opt/custom/smf/lxproc-fs.xml

Solaris + ZFS + KVM = SmartOS

Stabilní KVM na Solarisu? Je to tak! Projekt Illumos dostal díky Joyentu vlastní port KVM. SmartOS je na Illumos založená distribuce spojující ZFS, DTrace, Solaris zóny a ano, KVM!

Distribuce je to trochu nezvyklá, neinstaluje se na disk, ale spouští se z USB flash disku nebo bootuje pomocí PXE ze sítě. Většina filesystému je read-only, samotné služby se instalují až v zónách, pro jejichž správu Joyent přidal spoustu nástrojů.

Měl bych upozornit že KVM ve SmartOS funguje jen na serverech, jejichž procesory podporují EPT. Není to tedy virtualizační platforma pro starší stroje, ale 55xx a 56xx Xeony už EPT mají. Dokonce i bez podpory EPT SmartOS stojí za vyzkoušení. Dle mých testů jde 90% služeb které provozuji na Linuxu bez problému rozchodit i v Solaris zóně.

Za zmínku stojí ještě tyto věci:

  • „apt-like“ binární balíčkovací systém pkgin
  • SMF (Service Management Facility) jako advanced náhrada rc skriptů
  • Virtuální ethernet rozhraní, virtuální switche a virtuální routery – dá se s tím kouzlit 🙂
  • Nástroj imgadm pro práci s šablonami vps, spoustu předpripravených konfigurací vps
  • Perfektní správa zdrojů přidělených zónám a vps

Pokud spravujete vps na na Linux hostu, doporučuji SmartOS alespoň vyzkoušet.