Server pro VPS hosting - II.

17.3.2013 20:29 | Přečteno: 1835× | linux | poslední úprava: 26.3.2013 19:32

V druhém díle zápisu zkušeností z nákupu a konfigurace serveru pro VPS hosting se podíváme na ECC paměti, RAID, SSD disky a virtualizaci.

ECC paměti

Ve všech operačních pamětech dochází ke vzniku chyb. Podle některých zdrojů může docházet k jedné chybě každé 2 až 4 týdny na jeden GB paměti. Pokud tedy máme 16 GB paměti a rok běžící stroj, může jeho paměť obsahovat něco mezi 200 a 400 chybami. To se nemusí vůbec nijak projevit, může to ale také skončit jako kernel panic (v tom lepším případě).

Je tedy určitě vhodné se u dlouho běžících strojů těmto chybám bránit a to právě použitím ECC pamětí.

HW vs. SW RAID

Přestože se na první pohled může zdát, že softwarový RAID se nemůže se svým dražším bráškou porovnávat, není to vždy pravda. SW RAID nejen, že může být rychlejší, ale poskytuje také oproti HW RAIDU řadu výhod. Zvlášť pokud chceme použít RAID 1, 0 nebo 10, je použití softwarového RAIDu určitě dobré zvážit.

SSD disky

Solid-state disky jsou s námi už nějakou dobu a spoléhá na ně ve svých serverech řada velkých společností, není tedy důvod se jejich použití bát. Odměnou nám bude závratná rychlost čtení i zápisu (cca 500MB/s).

SSD disky mají jedno slabé místo - konečný počet zápisů do jedné buňky. Aby se s tímto problémem lépe popasovaly, snaží se disky zapisovat data do stále nových prázdných buněk, které ale mohou brzy dojít. Aby se to nestalo a disk pracoval stále stejně rychle a spolehlivě, je potřeba říkat mu příkazem TRIM, které buňky se už nepoužívají.

TRIM je v Linuxu implementován parametrem discard. Aby nám TRIM fungoval, je potřeba splnit několik podmínek:

• jádro alespoň 2.6.33 (nebo Redhat jádro 2.6.32, kde je backport)
• filesystém Ext4, Btrfs, Xfs, Gfs2 nebo Fat
• nepoužívat nad zařízením RAID

S parametrem discard si umí poradit také device-mapper (LVM).

Abychom omezili počet zápisů na SSD disk, je dobré /tmp namapovat do paměti (tmpfs). Případně můžeme také /var přesunout na klasický HDD, ale to ne vždy bude vhodné.

Virtualizace

Virtualizačních řešení existuje dnes celá řada a to jak placených, tak i open-source. Nejvíc mě zaujala platforma Proxmox VE, po jejímž objevení jsem začal o celém tomto počinu přemýšlet. Proxmox je open-source virtualizační platforma s krásným webový rozhraním a rychle rostoucí komunitou.

Proxmox je postavený nad stable Debianem a RedHat kernelem. K dispozici je instalační CD, díky kterému běhěm pár minut máte funkční virtualizační systém. Nebo je možné nainstalovat Debian přesně podle svých potřeb (debootstrap, SW RAID, LVM, EFI, apod.) a teprve poté do něj doplnit balíky Proxmoxu a kernel.

Proxmox nabízí jak plnou virtualizaci (KVM) tak virtualizaci na úrovni operačního sytému (OpenVz). Osobně budu používat OpenVz kontejnery, protože mají velmi malý overhead (cca 3%) a alokují zdroje on-demand (když kontejneru dáte 2GB RAM, neznamená to, že 2GB opravdu ubydou).

Pár poznámek k Proxmoxu:

• Vzdump, nástroj pro backupování kontejnerů, neumí inkrementální zálohy (což je možná dobře). Pokud je v kontejneru více uživatelských dat (> 1GB), je vhodné tyto data umístit mimo kontejner a do kontejneru je připojit pomocí bind. Data pak backupujeme zvlášť, vzdump se stará jen o backup systému.
• Pokud nepoužíváme cluster, jako backup hypervizoru stačí zálohovat /etc, Proxmox si nikam jinam žádná důležitá data neukládá.

UPDATE:
Zálohovat /etc nestačí, protože v /etc/pve je namountovaný proxmox cluster file system (v podstatě obsah sqlite DB), takže je potřeba zálohovat ještě /var/lib/pve-cluster/config.db.

       

Komentáře

[kralyk z abclinuxu]

U toho ECC by mě zajímalo, proč je to tak kritický na serveru a proč na desktopu to je prakticky šumák. Je to tím, že na desktopu se obsah RAM mnohem častěji obměňuje (ať už restartem nebo pestrostí činnosti)?

Byla by určitě moc zajímavá nějaká statistika o tom, kolik množsví chyb ECC ve skutečnosti na serveru odhalí a zaloguje za nějakej časovej úsek (měsíc, rok,...). Jsem si vědom, že něco takovýho publikoval google, ale zajímalo by mě, jak to je konkrétně třeba u tebe na VPS nebo na vpsFree kolegy snajpy.

[snajpa]

ECC pameti jsou totalne overrated, to je jedno z enterprise dogmat Ale kdyz chces vic jak 64GB RAM na CPU, tak uz si musis ECC pameti poridit, protoze potrebujes buffered moduly a ty jine nez ECC nesezenes.
Priklad z jednoho nodu z Prahy (ale tak je to na vsech):

[root@node9.prg.vpsfree.cz]
 ~ # edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: CPU_SrcID#0_Channel#0_DIMM#0: 0 Corrected Errors
mc0: csrow1: 0 Uncorrected Errors
mc0: csrow1: CPU_SrcID#0_Channel#0_DIMM#1: 0 Corrected Errors
mc0: csrow2: 0 Uncorrected Errors
mc0: csrow2: CPU_SrcID#0_Channel#1_DIMM#0: 0 Corrected Errors
mc0: csrow3: 0 Uncorrected Errors
mc0: csrow3: CPU_SrcID#0_Channel#1_DIMM#1: 0 Corrected Errors
mc0: csrow4: 0 Uncorrected Errors
mc0: csrow4: CPU_SrcID#0_Channel#2_DIMM#0: 0 Corrected Errors
mc0: csrow5: 0 Uncorrected Errors
mc0: csrow5: CPU_SrcID#0_Channel#2_DIMM#1: 0 Corrected Errors
mc0: csrow6: 0 Uncorrected Errors
mc0: csrow6: CPU_SrcID#0_Channel#3_DIMM#0: 0 Corrected Errors
mc0: csrow7: 0 Uncorrected Errors
mc0: csrow7: CPU_SrcID#0_Channel#3_DIMM#1: 0 Corrected Errors
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info
mc1: csrow0: 0 Uncorrected Errors
mc1: csrow0: CPU_SrcID#1_Channel#0_DIMM#0: 0 Corrected Errors
mc1: csrow1: 0 Uncorrected Errors
mc1: csrow1: CPU_SrcID#1_Channel#0_DIMM#1: 0 Corrected Errors
mc1: csrow2: 0 Uncorrected Errors
mc1: csrow2: CPU_SrcID#1_Channel#1_DIMM#0: 0 Corrected Errors
mc1: csrow3: 0 Uncorrected Errors
mc1: csrow3: CPU_SrcID#1_Channel#1_DIMM#1: 0 Corrected Errors
mc1: csrow4: 0 Uncorrected Errors
mc1: csrow4: CPU_SrcID#1_Channel#2_DIMM#0: 0 Corrected Errors
mc1: csrow5: 0 Uncorrected Errors
mc1: csrow5: CPU_SrcID#1_Channel#2_DIMM#1: 0 Corrected Errors
mc1: csrow6: 0 Uncorrected Errors
mc1: csrow6: CPU_SrcID#1_Channel#3_DIMM#0: 0 Corrected Errors
mc1: csrow7: 0 Uncorrected Errors
mc1: csrow7: CPU_SrcID#1_Channel#3_DIMM#1: 0 Corrected Errors
[root@node9.prg.vpsfree.cz]
 ~ # uptime
 01:29:49 up 108 days, 23:44,  1 user,  load average: 13.10, 13.43, 15.06

[Dundee5]

To je dost překvapivá informace :) Ještě jsem neviděl žádnou statistiku, která by říkala, že se ECC nevyplatí...

V desktopu se to imho nepoužívá jednak kvůli častějším restartům (chyby se tolik neakumulují) a také prostě proto, že spolehlivost není tak důležitá. Jedna BSOD za rok nikoho nezabije.

[snajpa]

Asi zalezi na prostredi, jak moc do nej pronika kosmicke zareni a podobne. Nicmene u nas v racku ECC pameti moc rozdilu nenadelaji. Na druhou stranu, pokud platim 2500 Kc bez DPH za 16GB DDR3 ECC 1600MHz modul, tak je mi celkem jedno, jestli je to, nebo neni ECC, jsou to celkem smesne penize

[Dundee5]

Kde jsi viděl tak dobrou nabídku? Prošel jsem pár obchodů (alza, atcomp, agem) a nikde jsem tak dobrou nabídku neviděl. Koukal jsem ale na unbuffered ECC paměti.

[snajpa]

Tady, s moji cenovou urovni to dava 3150 s DPH, bez ni 3600, coz porad jde, rekl bych.

[bogo]

Taky se to na desktopu nepouziva proto, ze intel desktopove cpu to vubec nepodporuji (afaik). AMD alespon na socketu AMx ano, na FMx netusim. Plus spousta kiddies co si vsechno pretaktuji...

BTW pro zajimavost, nvidia tesla umi ECC ale ma moznost to vypnout, protoze to spomaluje operace s pameti o nejakych 5% jak je to u cpu ramek ale nevim.

Jinak souhlas se snajpou, ECC je overrated - IMHO to nejvic pomaha zjistit kdy pameti fyzicky zestarnou k nespolehlivosti, coz by melo chvilku trvat... takze by mozna stacilo po dvou letech ramky prodat a koupit nove, nebo rovnou vymenit celej server

[Honza Jaroš]

Sedmičkový Debian, zdá se, nebude OpenVZ podporovat. Počítá s tím Proxmox nějak do budoucna?

[Dundee5]

Ano. Proxmox vůbec nepoužívá OpenVz balíky z Debianu. Kernel používá z RHELu 6 a OpenVz nástroje si kompilují sami ze zdrojáků.

[David Jaša]

4 GB nebo 8 GB RAM pro stroj pro virtualizaci? Tedy, ne, že by to nešlo, ale přijde mi to jako dělat z osobáku kamion. Ono obecně s virtualizací je to obráceně, než u nákupu "klasickýho" železa - čím větší stroj, tím míň si hypervizor ukousne z celkových systémových prostředků, a tím větší šance na efektivní využití jader CPU.

Osobně budu používat OpenVz kontejnery, protože mají velmi malý overhead (cca 3%) a alokují zdroje on-demand (když kontejneru dáte 2GB RAM, neznamená to, že 2GB opravdu ubydou).

Ta tvrzení jsou přinejmenším nepřesná. U KVM se alokují zdroje také on-demand, nicméně pro paměť žádná odboba TRIM neexistuje a když widle při bootu přepíšou celou paměť nulama, holt se celá obsadí. Nicméně to není navždy, jsou dvě možnosti, jak vzít paměť zpět:

• Pokud běží více "stejných" strojů, KSM je schopné samo o sobě srazit využitou paměť na úroveň kontejnerové virtualizace, protože qemu a jádro + OS + aplikace guestů jsou v paměti jen jednou
• pokud ani tohle nestačí, dá se ve volném místě virtuálky nafukovat balón a takto označené místo opět může využívat hypervizor.

[Dundee5]

8GB by mělo stačit pro počáteční rozjezd, kdy tam bude jen pár klientů.

Aha, díky za info. Myslel jsem, že KVM tu paměť celou zarezervuje.