Archiv pro rubriku: SmartOS

Jak přesunout SmartOS image z jednoho serveru na druhý

Nedávno se mi stalo, že jsem potřeboval přesouvat SmartOS zónu z jednoho serveru na druhý. Zóna ale byla vyrobená z obrazu base-64-lts ve verzi 16.4.0. Tuhle verzi kvůli fatální chybě při upgradu stáhli z veřejného repozitáře.

Řešením by bylo dataset zóny povýšit pomocí zfs promote. Co když ale raději chceme origin zóny zachovat a přenést jej na nový server? Nástroj imgadm bohužel nic jako export neposkytuje. Naštěstí si ale můžeme poradit ručně.

Nejprve přeneseme dataset:

Poté přesuneme konfiguraci pro imgadm:

Nesmíme zapomenout na lock soubor, který imgadm používá, aby určil, zda je již daný image naimportovaný:

A to je vše 🙂

Jak dostat ze SmartOS data o prostředcích VM

Na SmartOS nám spoustu věcí o VM prozradí příkaz vmadm. Např. základní limity zjistíme takto:

Je ale docela otrava to pokaždé zadávat. Můžeme si na to samozřejmě udělat bash alias, což jsem také měl. Další užitečný alias mám např. na výpis VM:

Na výpis prostředků už mi ale pouhý alias nestačil. Sepsal jsem tedy jednoduchý skript. Ten krom toho, co vrací vmadm, zobrazí i kolik VM žere místa na disku v přehledné formě. Navíc je to pěkná ukázka, jak se můžete podobné užitečné skripty sepsat sami.

Rozhodl jsem se nejen skript vmusage, ale celý repozitář s pár dalšími užitečnými věcmi zveřejnit. Stahovat nebo forkovat repozitář solaris-scripts můžete na BitBucketu.

Jak vytvořit Ubuntu image pro SmartOS

Po nějaké době vás přestane bavit instalovat všechny nové VPS z ISO image. Nastal čas vytvořit si image pro imgadm. Jak na to?

Vytvoříme si prázdný VPS:

Stáhneme instalační ISO a nabootujeme z něj VPS:

Získáme info o VNC a připojíme se na něj:

Nyní nainstalujeme Ubuntu (nebo jiný OS) jak jsme zvyklí. U ubuntu ještě doporučuji pomocí F4 zvolit volbu „Install a minimal virtual machine“.

Po instalaci uděláme aktualizaci systému a reboot:

Po rebootu odstraníme staré kernely:

Volitelně také můžeme vyhodit hlavičkové soubory, které ve většině případů nejsou potřeba, ale aktualizují se zbytečně s každým kernelem:

Můžeme doinstalovat nějaké balíky. Rozhodně ale nesmíme vynechat balík acpid:

Můžeme také některé přebytečné balíky vyhodit:

Dále nainstalujeme sdc-vmtools:

P5ihlásíme se přes VNC a ostraníme uživatele, kterého jsme vytvořili při instalaci systému:

Připravíme VPS na vypnutí:

Rootovi můžeme nyní odebrat heslo:

Shodíme VPS a vratíme se do SmartOS:

Vytvoříme z VPS image:

A VPS smažeme:

Pro image potřebujeme vytvořit dsmanifest:

UUID pro creator_uuid a vendor_uuid si můžete vygenerovat příkazem uuid.

Máme image a dsmanifest, teď image můžeme nainstalovat:

A teď z image konečně vytvoříme VPS:

Nemá smysl dávat disku větší size, než je size image. Disk se stejně vytvoří podle image. Prozatím to řeším pomocí GParted. Jakmile budu vědět, jak to zautomatizovat, napíšu o tom další článek. Nebo můžete někdo poradit v diskuzi pod článkem 🙂

Dodatek: dá se to řešit takto:

Jak připravit SmartOS na Ansible

Se SmartOS je po instalaci trochu problém. Aby na něm Ansible fungoval, je potřeba pár věcí udělat ručně.

Nainstalovat pkgsrc bootstrap do globální zóny:

Můžeme rovnou provést upgrade balíků:

Doinstalujeme python:

Volitelně povolíme ssh klíč:

Pokud nechcete přidávat klíč, stačí spustit ansible-playbook s prametrem -k, aby se zeptal na heslo.

SmartOS chyba při spouštění /smartdc/bin/sdc-lastcomm cronem

Pokud už vás nebaví po přihlášení do SmartOS global zóny hláška You have new mail a vidíte ve /var/mail/root chybu:

má to snadnou nápravu. Bude ale potřeba upravit soubor /smartdc/bin/sdc-lastcomm. Abych si to zjednodušil, vytvořil jsem patch:

Patch nejlépe provede takto:

Více info v Github repozitáři SmartOS

Update: 15.10.2015 upraveno pro verzi 20151015T063628Z

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:

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:

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

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:

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:

Nastavení NTP v globální zóně SmartOS

V nedávné době se na internetu začala hojně zneužívat chyba v NTP serveru, který je na mnoha serverech defaultně povolen. SmartOS v tomto nebyl vyjímkou. V aktuální verzi (20140404T001635Z) je již chyba v konfiguraci NTP na SmartOS opravena, nejlepším řešením je tedy upgrade SmartOS. Pro ty, co si ale chtějí do NTP nastavit české servery tu mám krátký návod, jak ntp.conf přetížit.

Tento konfigurační soubor ntp.conf uložíme do souboru /usbkey/config.inc/ntp.conf

Pokud složku config.inc ještě nemáte vytvořenou, tak ji vytvořte.

Config poté aktivujeme přidáním následujícího řádku na konec souboru /usbkey/config

Změny se projeví až po restartu stroje. Eventuelně můžete config nakopírovat do souboru /etc/inet/ntp.conf a restartovat NTP příkazem:

SmartOS, su a ENV proměnná HOME

Na Linuxu jsem byl zvyklý, že když zavolám su <user>, ENV proměnná HOME se nastaví na domovský adresář uživatele. Na SmartOS (nejsem si jist, jak na Solaris) se tohle ale nestane. Tohle chování mi vadilo hlavně při používání GITu. Dostal jsem tuto chybu:

Řešení je jednoduché. Místo su použijeme příkaz sudo. Konkrétně takto:

Abychom si to zjednodušili a nemuseli si nový příkaz pamatovat, můžeme si jej přidat jako alias do souboru ~/.bashrc

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:

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

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?

  • 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?

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