proc_meminfo_read()
z LXCFS: https://github.com/lxc/lxcfs/blob/master/bindings.c#L3174Toto je starší verze dokumentu!
Protože OpenVZ už pomalu dosluhuje a nové distribuce jej nepodporují, museli jsme začít řešit přechod na nějakou novější virtualizační technologii. Linux kernel už sám o sobě kontejnery do jisté míry podporuje, takže jsme se rozhodli toho využít. Dále jsme potřebovali nějakou distribuci, kterou bychom použili na nodech místo Scientific Linux 6 s OpenVZ kernelem. Volba padla na NixOS, který umožňuje deklarativně definovat konfiguraci OS a služeb a pak jej opakovatelně sestavit. A protože máme specifické nároky, stavíme si nad NixOS vlastní distribuci.
vpsAdminOS je založen na
NixOS a not-os.
Je to live distribuce sloužící jako hypervizor pro provoz kontejnerů.
vpsAdminOS je funkčností srovnatelný s OpenVZ Legacy. Jako základ pro provoz VPS
(kontejnerů) slouží LXC, které spravujeme vlastní utilitou osctl
z vpsAdminOS. vpsAdminOS umožnuje propojení s vpsAdminem, naším administračním
rozhraním, nicmeně je plně použitelný i bez něj a měla by to být plnohodnotná
náhrada za OpenVZ Legacy, pokud jej někde používáte. Podporována je i
migrace kontejnerů
z OpenVZ Legacy na vpsAdminOS.
Přechod celé naší infrastruktury se všemi VPS na vpsAdminOS je rozdělen do několika fází:
Snažíme se, aby migrace na vpsAdminOS byla bezproblémová, tj. aby se jednoho dne VPS vypl na OpenVZ nodu a spustil na vpsAdminOS, aniž by člen něco musel řešit. Nicméně, záleží na tom, co ve VPS provozujete. Proto všem doporučujeme vyzkoušet si VPS nad vpsAdminOS v testovacím prostředí, abychom mohli případné nedostatky vyřešit a při následné migraci produkčních VPS se jim vyhnout.
Linux kernel nemá nic jako venet z OpenVZ, takže jsme si museli pomoci jinak. Síťování je řešeno přes dvojici rozhraní veth: jeden na nodu a druhý ve VPS. IP adresy VPS jsou routovány přes spojovací síť, která je každému VPS přidělena.
Například, přidělená spojovací síť pro IPv4 je 10.100.10.0/30
. Veth rozhraní
na nodu bude mít adresu 10.100.10.1
, veth rozhraní ve VPS pak
10.100.10.2
. Veřejné IP adresy VPS jsou routovány přes 10.100.10.2
,
např. veřejná IPv4 1.2.3.4
by byla routována jako
1.2.3.4/32 via 10.100.10.2
. Výchozí routa pro VPS je pak nastavena jako
default via 10.100.10.1 src 1.2.3.4
. Rozhraní na nodu se konfiguruje
automaticky, ve VPS se pak automaticky generují konfigurační soubory, které
váš init systém používá k nastavení sítě, takže nic řešit nemusíte. První
adresa na síťovém rozhraní ve VPS je však adresa spojovací, nikoli veřejná,
jako tomu bylo doposud. Pokud si konfiguraci sítě upravujete, musíte se tomuto
nastavení přizpůsobit.
VPS ve vpsAdminOS využívají user namespace, tzn. root ve VPS má UID 0, ale z pohledu hostitelského systému na nodu je to nějaké jiné číslo, např. 666000. Každý člen má pak přidělen svůj user namespace, což zvyšuje úroveň izolace – v případě nějaké chyby se útočník ani po úniku z kontejneru na node nedostane k datům jiných členů.
Každý člen má přidělen user namespace o velikosti 524288 uživatelských ID. Tzn. ve VPS můžete využít UID/GID od 0 do 524287. Všechny VPS daného člena jsou umístěny do tohoto user namespace. V budoucnu přibyde možnost si user namespace spravovat a nastavovat si vlastní mapování UID/GID, což umožní izolovat od sebe i VPS patřící jednomu členovi, případně vybrané UID/GID sdílet.
User namespace podstatně ovlivňují sdílení dat mezi VPS a NASem. Aktuálně není možné připojit NAS do VPS běžící na vpsAdminOS tak, aby měl VPS k datům přístup. Řešit se to bude tak, že u každého NAS datasetu budete mít na výběr, jaké mapování UID/GID má používat. Data pak budou přistupná jen z VPS, které mají nastaveno příslušné mapování.
Změny týkající se VPS nezávisle na distribuci:
/proc/loadavg
ukazuje loadavg celého nodu, tj. všech procesů ze všech VPS na nodu, nevypovídá to nic o aktuální VPS/proc/meminfo
1)dmesg
je zakázán, neboť není virtualizovánifconfig
z net-tools
, používá se ip
z iproute2
./etc/network/interfaces.{head,tail}
nejsou vkládány přímo do /etc/network/interfaces
, ale načteny přes source
, tzn. už neovlivňují podobu /etc/network/interfaces
tak jako s vzctl./etc/network/interfaces.d
, jeho obsah je načten před /etc/network/interfaces.tail
.venet0
.Aby si všichni členové mohli vyzkoušet, jak se VPS nad vpsAdminOS chová, k dispozicí je testovací prostředí, tzn. takový druhý playground node, na kterém si každý může vytvořit VPS. Ve formuláři na vytváření VPS stačí vybrat lokaci Staging.
Podmínky provozu jsou podobné jako pro playground VPS, akorát to může být trochu divočejší, tj. nehlášené výpadky, restarty pokud potřebujeme něco aktualizovat. Každý má k dispozici 8 CPU, 4 GB RAM, 120 GB disku, 4 veřejné IPv4 adresy, 32 IPv6 /64 adres a tyto prostředky lze rozdělit mezi 4 VPS.
V současné době není možné klonovat/swapovat produkční VPS s testovacími VPS na vpsAdminOS. Proces migrace VPS z OpenVZ na vpsAdminOS ještě není dořešen. Omezen je také přístup k NASu, viz user namespaces.
Pokud tvoje distribuce zatím není mezi podporovanými, můžeš nám pomoct ji zprovoznit, nebo nezbývá než počkat, až to za tebe udělá někdo jiný, viz otevřené požadavky.
Šablony distribucí se vytvářejí skripty ve vpsadminos-templates. Pokud tam tvá distribuce není, je potřeba ji zde přidat.
Dále je nutné vyřešit podporu dané distribuce ve vpsAdminOS tak, aby byl
osctl
schopen zvenku nastavovat síť a IP adresy. Stačí postupovat
podle návodu. Je potřeba
implementovat podporu jak pro bridged veth, tak routed veth, viz
dokumentace vpsAdminOS
a zdrojové kódy.
Podle vlastního uvážení:
proc_meminfo_read()
z LXCFS: https://github.com/lxc/lxcfs/blob/master/bindings.c#L3174