Dotaz: Nový server, co koupit? Koupit železo nebo udělat virtual

[chinook]

Mám už asi 8 let čtyři servery. Jeden je jako firewall a běží na něm antispam. Na druhém běží pošťák a fileserver, natřetím běží databáze a čtvrtý slouží jako záložní, jsou na něm sychnronizovány data přes DRBD a je možné jakoukoliv službu ze zbývajících tří serverů na něm spustit. Zatím nemám s HW žádný problém, ale jeden server již nelze aktualizovat a druhý již také nemá úplně podporu, tak bych to chtěl postupně začít měnit. Otázkou je co pořídit.

A) Napadlo mě koupit jeden výkoný server, tam dát 4TB disky do raidu pro fileserver, pak rychle disky 750GB na poštu (nebo jak levně udělat rychlé pole) a další rychlé disky např 512GB pro postgres. Všechny služby bych zprovovznil na tomto serveru a jen každá by měla jinde úložiště (fileserver 4TB pole, pošťák 750GB a DB svoje disky) Místo FW bych koupil něco od mikrotiku.

TO bych koupil 2x a propojil přes DRBD.

B) Má smysl kupovat server pro pošťáka pak další pro postgres a další jako fileserver a čtvrtý jako záložní v podstatě tak jak to mám? Místo FW bych koupil něco od mikrotiku.

C) Koupím stejně výkoný server i s diskama jako za A) a každý server dám do virtuálu klidně do nějakého VMWARE. Jediné co asi získám je pak následný přesun na nový server nebo jaký to má smysl? Místo FW bych koupil něco od mikrotiku.

D) Koupím výkoný server zvolím variantu buď A nebo C a k tomu koupím pole? Musím je kupovat 2x, abych zajistil výpadek? Místo FW bych koupil něco od mikrotiku.

E) Zvolím nějakou variantu výše a koupím ještě jeden server jako FW nebo co použít místo FW?

Další varianta mě nenapadá, pokud je něco vhodnějšího sem s tím :)

Odpovědi

[PanZvedavy]

1. dle potreby vykonu koupis 4-6-8 jadro, pokud si pockas 1-2 mesice tak zrovna AMD chysta novej procak, kterej vypada, ze bude drtit(jak kde,jak v cem) vykonem a predevsim cenou intely
2. pokud jsou pozadavkem ECC ramky tak ebay, jsou tam mraky Xeonu od 4 az do 20 jader, nebo hotove sestavy treba s 2x Xenonem s 8 jadrama, neni mozne si nevybrat.
3. koupit 2 1TB ssd a 2 4TB hdd
4. na stroj nainstalovat treba Proxmox, kterej stavi na debianu, takze to neni blackbox jako vmware.
5. na prvni 1TB ssd nainstalovat Proxmox a zaroven na nem hostovat virtual s postou
6. na druhej 1TB ssd dat virtual s postgresem
7. zbytek pobezi ve virtualech na 4TB hdd, ktere budou v raid1

Jako FW poslouzi samotnej proxmox, protoze je to debian vcetne iptables.
Na siti pak nejakej dvoudiskovej box s 8TB diskama v raid1 a do nej nalejvat zalohy virtualu atd.
Sam to takhle nejak v principu provozuji.

[R]

To myslis vazne, ze prevadzkovat server na SSD bez RAIDu? Tie serverove 1TB SSD budu drahsie ako cely ostatny HW dokopy.

[chinook]

Jak píše R, sice si raději připlatím ať mně to vydrží zase 10let, ale nedám 100tis. za disky.

A server nechci nijak skládat, koupím něco od DELLu.

[PanZvedavy]

Provozuju nekolik systemu, kde mam SSD(intely) na OS + nejaky ten virtual. Za ty roky jsem jeste neprisel o zadna data z duvodu kolapsu HW u SSD(+kazdodenni zaloha je samozrejmosti). Raid u klasickejch disku je bez debat, ale raidovat 128-256-512GB SSD? Jeste jsem u ssd neslysel cvakat hlavicku nad plotnama :) A ano, pokud mam SAN na SSD, tak logicky z toho neudelam jbod nebo raid0, ale raid6,10. Ale raidovat SSD na OS + 1-3 virtualy pri dennich zalohach?

[vandrovnik]

Taky se dá udělat Raid 1 z SSD a plotnového disku, přičemž ten plotnový disk se označí jako write-mostly. Přijde mi to lepší, než nechat SSD samotné.

W, --write-mostly
              subsequent devices listed in a --build, --create, or --add  com‐
              mand will be flagged as 'write-mostly'.  This is valid for RAID1
              only and means that the 'md'  driver  will  avoid  reading  from
              these devices if at all possible.  This can be useful if mirror‐
              ing over a slow link.

[Jendа]

To je zajímavá funkce, ale záleží na zátěži, jestli to pomůže - e.g. u poštovního serveru asi ne (při příjmu mailu ho to musí uložit, při odesílání přesunout/označit), u databáze záleží, jestli je hodně čtecí, nebo data i mění.

[R]

Viem o jednom "serveri" s jednym diskom (obycajnym desktopovym, este PATA) bez RAIDu, ktory bezal vela rokov a tiez o data neprisli. Potom na tom serveri nastastie odislo nieco ine - vybila sa CMOS bateria, tak po vypadku uz nenabehol. A ked som ho rozoberal, tak som zistil, ze navyse odpadol chladic z chipsetu. Mame nastastie kopu starych serverov, tak som namiesto neho pouzil nejaky IBM s RAIDom a SCSI HDD.

Napr. pri mail serveri je RAID dost dolezity - ked stratis aktualne maily za pol dna, tak je ti cela zaloha na dve veci... Nehovoriac o tom, ze uz samotny vypadok mail serveru je problem.

[R]

Podpora/zaruka od vyrobcu pri novom serveri je sice pekna vec, lenze aj ked mas drahu 4-hodinovu podporu, tak to stale moze byt vela. V tom pripade je lepsie mat pripraveny druhy server, ktory mozes hned pouzit (ci uz ako cluster alebo to za 20 minut prehodis rucne). Pouzivame

Samotne diskove pole nekupuj, pokial to nebude vyslovene nutne. Kvalitne pole je interne plne redundantne (vsetko je zdvojene), takze by stacilo jedno. Ale vyslo by to drahsie ako bez neho a redundancia by bola horsia (mal by si 2x menej diskov). Pre taketo male veci su to vyhodene peniaze.

[R]

Odoslal som to predcasne: Pouzivame servery aj po zaruke, hlavne DELL a nic sa neserie - napriklad zdroj neodisiel nikdy. V jednom type odchadzal jeden model 2,5" diskov. Takze staci nakupit nahradne disky (eBay), otestovat ich(!) a mat pripravene pre pripad, ze nejaky odide. Samozrejme to predpoklada mat funkcne varovanie pri poruchach - na urovni OS (smartmontools, megaclisas_status a pod.) aj na urovni HW (DRAC, iLO).

[chinook]

Takhle nějak to provozuji. Za 8 let provozu na 3 serverech jsem vyměnil asi 4 disky nidky nebyl žádný výpadek. Je to asi 5 let po záruce. Vše DELL a koupím zase DELL.

Co myslíš tím polem, že bych měl 2x méně disků? Když koupím všechny servery 2x, tak taky budu mít méně disků?

A furt nevím jakou variantu zvolit, viz. můj ůvodní příspěvek.

[R]

Myslel som to takto:

1) 2 replikovane servery a v kazdom RAID1 - tzn. data su na 4 diskoch.

vs.

2) 1 diskove pole s RAID1 pripojene k 2 serverom - data su na 2 diskoch.

Takze v 2. pripade mas mensiu redundanciu dat, pravdepodobne za vyssiu cenu.

[Michal]

Dej si to někam do cloudu, třeba do Amazon AWS, a máš po starostech s hardwarem. Databázi to RDS, pošťáka do EC2 a všechno pravidelně snapshotovat, monitorovat, nastavit auto-healing, atd. Bude tě to sice možná stát o něco víc na provoz ale zase ušetříš na pořizovacích nákladech. My jsme si spočítali že než udržovat UPS, klimatizaci pro serverovnu a pár HW serverů tak se nám vyplatí to nacpat do AWS a mít od hardwaru pokoj. Když se to udělá dobře je to spolehlivější a nakonec levnější než vlastní železo.

[R]

Ak firma nic nerobi, nema vela dat a nezalezi jej na bezpecnosti, tak je to mozne. Akurat ked vypadne linka do internetu, neposles ani kolegovi mail.

[GothiqueNoir]

Co mail, ale ani uctovnictvo, ani firemna databaza, ani projekty na fileserveroch - nic... proste si mozes kavu varit - ak nemas kavovar niekde v CLOUDE...

[Michal]

Tak uprimne - jak casto vam vypadava linka do internetu? Nam naposledy pred nejakymi trema lety a pred tim hooodne davno. Samozrejme pokud jste porad na dial-upu tak to je neco joneho.

No a s tou bezpecnosti - jaky si to udelas, takovy to mas. Neslysel jsem o pripadu kdy by se nekdo naboural do ciziho VM v AWS vinou Amazonu. Holt si to musis zabezpecit stejne jako on-prem sit.

Jako jo, je riziko ze Amazon prestane existovat a o sva data prijdes. Ok, zalohuj to jinam.

Beru jen argument ze kdyz mate hodne velkych souboru (dejme tomu graficke studio) tak je musite mit blizko kvuli rychlosti pristupu - ale i na to jsou metody jako treba AWS StorageGateway, coz je lokalni cache zalohujici do AWS.

Ale na mail, bezny kancelarsky file server, build pipeline, ruzne wiki, atd je z meho pohledu AWS cloud lepsi reseni.

[chinook]

Coud nepřipadá v úvahu, nejde o linku ani sám osobně si nemyslím, že je amazon zvědavej na nějakou poštu, ale prostě chceme mít server u sebe i když víme, že to je dražší.

[k3dAR]

kdo je neschopnej poridit, nebo spravovat vlastni HW, tak si cmoud vzdycky jako neco vyhodnejsiho okeca, fakt je ale takovej ze je to takovej dnesni MOR a vlastni HW je vlastni HW...

[little-drunk-jesus]

V dnesni dobe neni potreba byt tak striktni - Orchestratory pro docker umi federovane clustery - je pak mozne zacit s hybridni architekturou, kdy mam jeden nastroj - jeden cloud s tim, ze cast workloadu bezi u me (klidne to ucetnictvi nejake interni db atp) a zbytek hodim ven (vetsinou sluzba smerujici na zakazniky, kterou chci mit moznost nejak skalovat s nejakou rozumnou dostupnosti) - Do toho muzu hodne usetrit, ze na nejake one time tasky(reporting) pouziju nejake bidding instance, pripadne prebytecny vykon u sebe na serverech - proste co zrovna mam k dispozici). Tenhle zpusob mi prijde jako celkem fajn reseni.

[honza]

Podla klucoveho slova "cmoud" sa daju vytrackovat vase negativne cloud prispevky na internete :-P.

Aj ked sa vam to nepaci, tak cloud ma svoje miesto. Specialne pokial workload nie je stabilny. Napr. pri spracovavani dat. Spustis si cluster napr. 1TB RAM/300CPUs, spracujes data za par dni a koniec. Pri vlastnom HW by bol HW vacsinou nevyuzity. Mohol by mat pripadne mensi sizing, ale to by uz pocitalo mozno az tak pomaly, ze ked dostanem vysledok uz by bol neaktualny. Taktiez rychlost inovacii u cloud providerov je uzasna. Nepopieram, ze takmer vsetko si vies urobit aj na vlastnom HW, avsak chce to cas/ludi/peniaze. Vo velkej vacsine pripadov mi pride lacnejsie pouzit hned cloud ked je potreba ako cakat az bude dostupny/nainstalovany HW pozadovanych parametrov.

Cloud sa nemusi vyplatit pokial mas stabilny a predpovedatelny workload. Viem si predpovedat, ze potrebujem LAMP server na moj blog. Mozem si ho urobit v cloude ($5/mesiac - Digital Ocean/AWS) alebo na vlastnom HW. Moj cas na jeho spravu by vsak bol drahsi, tak si to rovno kupim ako sluzbu webhostingu a uz sa viac o to nestaram :-P

[k3dAR]

jenze tady je rec o serveru pro email(800MB), file(2TB), db(40GB) a backup kdy 4 stavajici 8let stare servery co maji dohromady jen 20GB RAM jsou predimenzovane... v takovem pripade opravdu plati ze vlastni HW je vlastni HW ;)

[chinook]

Přesně tak. Cloud doopravdy ne i když by možná vyšel levněji. A zátěž je plus mínus furt stejná pokud pominu noc.

[R]

Ked mam sukromny kluc na svojom (fyzicky zabezpecenom) serveri, nebezi mi tam ziadny nedoveryhodny SW a nema tam pristup nikto, tak ten kluc ostane sukromny.

Ked si ho tam na nejaky virtual niekam do prdele, tak nie.

[chinook]

Do cloudu to určitě dávat nechci, chci mít všechna data u sebe, to že to je o něco dražší mně nevadí.

[NN]

Nepises podstatne veci, jako kolik do toho chces nasypat a v jakych objemech surovych dat, sitoveho provozu, vykonu, spotrebe etc. se vlastne vubec realne pohybujes a jakou mas predstavu vyvoje. Zatim je to cista fantazie..

[chinook]

Dám do toho tolik kolik bude potřeba. Rozhodně nic nebudu skládat nebo něco bastlit, abych ušetřil pár korun a pak se s tím budu otravovat. Zprovozním to vše na serverových dílech.

Tak DB má asi 40GB resp. všechny dohromady.

PoŠta asi 800GB

A fileserver tak 2TB

1GB karta by podle mě utáhla v pohodě všechny 3 současné servery na síť to není náročné.

S výkonem není problém CPU nikde nic nedělá a jsou to 8 let staré servery. Ram tam je na všech dohromady do 20GB.

Představou vývoje je myšleno co? Chci to zapojit tak, abych to měl zdvojené a vpřípadě výpadku jednoho železa to ručně přepnu nadruhé, tak to mám i teď. Ale zatím to nikdy nebylo potřeba.

A chci s tím zase 8-10let vydržet, teď spíš dělám upgrade, že např. to centos co bylo nainstalováno před 8lety nemá žádnou podporu a již nějakej rok nebylo ani aktualizováno. S HW zatím žádnej problém nemám. Klidně to budu pomalu přesouvat rok službu po službě zatím na mě nic netlačí.

[Jendа]

Dva servery, služby do virtuálů (jednoznačně KVM) kvůli jednodušší správě a upgradování a replikovat data.

„Rychlé disky“ nevím jestli má dneska cenu kupovat jako rotační, SSDčka šla strašně dolu. Ale samozřejmě do RAIDu (to mi přišlo samozřejmé, ale nahoře nějaký člověk radí bez něj).

E) Zvolím nějakou variantu výše a koupím ještě jeden server jako FW nebo co použít místo FW?

Budeš virtualizovat na KVM, takže použij prostě linuxový netfilter na hostiteli.

[chinook]

Rychlé disky tedy koupím jednoznačně ssd a samo do raidu. Jaká je výhoda, když udělám pět virtuálních serverů na jednom železe? Ještě nikde a nikdy se mně nestalo, že by spadl celý systém pokud neodešel HW. Vyzkoušeno na desítkách instalací.

Není bezpečnostní riziko zprovoznit firewall na hostitelském počítači? Když se někdo dostane na FW odnese si všechny stroje.

Klidně to budu provozovat na KVM. WMVARE znám a přijde mně jednodušší. Ale KVM se můžu naučit s tím problém není.

[Jendа]

Jaká je výhoda, když udělám pět virtuálních serverů na jednom železe?

Na hostitelský systém se moc nesahá a když se ti podaří rozbít virtuál, opravuje se to lépe, než na fyzickém železe.

Například Apple Calendarserver je v Debianu 7 a 9, ale ne v Debianu 8. Když to jsou samostatné systémy, tak můžeš fileserver a poštu upgradovat a ta jedna služba holt počká na starém systému.

Když ti někdo hackne jedno z toho, nedostane se do ostatních .

Není bezpečnostní riziko zprovoznit firewall na hostitelském počítači? Když se někdo dostane na FW odnese si všechny stroje.

Doufám, že díry v netfilteru zneužitelné jen při nějaké kombinaci pravidel se nedějí.

Klidně to budu provozovat na KVM. WMVARE znám a přijde mně jednodušší. Ale KVM se můžu naučit s tím problém není.

Já zase neznám VmWare a odnesl jsem si z toho, že hostitelský systém nic pořádného neumí a není to prostě Linux kde si můžeš cokoli snadno naskriptovat, různé věci si člověk musí dokoupit a adminuje se to pomocí Windows-only aplikace (wtf).

[chinook]

To je vlastně pravda, že se pak bude dělat na virtuálech pohodlněji upgrade a když mně to někdo hackne jeden, druhý je v pohodě.

Ok Koupit tedy dva silné stroje. Na ně hodit KVM, data replikovat. Dále bych tam postavil nějaký HW raid 5 o kapacitě 4TB z disků 7200ot. Tam bych nainstaloval všechny virtuály a data by pošŤák a SQL server měl na SSD v raid 1?

A ten firewall z mikrotiku je blbost? Furt se mně je nějak proti srsti mít fw na železe kde běží ostatní stroje.

[Max]

Jak už jsem napsal níže, RAID10 je tvůj kámoš, na RAID5 zapomeň. Nevím, jak moc máš vytíženou tu SQL db, ale myslím si (dle zkušeností s podobnýma kapacitama apod.), že to v klidu všechno dáš na 6x1,2TB SAS 10k diskách v RAID10 s nějakým rozumným cachováním (buď v podobě hw raidu a BBWC, nebo v podobě nějakého FS, co cachuje do ram, nebo na ssd).
Zdar Max

[Max]

Jinak když jsem sizoval nové pole, tak jsem si spočítal IOPs na všech serverech. Tím by jsi mohl začít, aby jsi se jen ujistil, že to těch 6 disků dá v klidu.
Zdar Max

[chinook]

Tak už mám nějaký návrh, vzal bych toto 2x.

2.5" Chassis with up to 8 Hot Plug Hard Drives
Intel Xeon E5-2640 v4 2.4GHz,25M Cache,8.0GT/s QPI,Turbo,HT,10C/20T (90W) Max Mem 2133MHz
Bezel up to 8 Drive Chassis
Riser with Two x16 PCIe Gen3 LP slots (x16 PCIe lanes),
R430iDRAC Port CardPerformance Optimized4x
16GB RDIMM, 2400MT/s, Dual Rank, x8 Data Width
135W HeatsinkiDRAC8 Enterprise, integrated Dell Remote Access Controller, Enterprise6x 1.2TB 10K RPM SAS 2.5in Hot-plug Hard Drive
PERC H730 Integrated RAID Controller, 1GB CacheDVD+/-RW SATA InternalDual, Hot-plug, Redundant Power Supply (1+1), 550W
2x C13 to C14, PDU Style, 10 AMP, 6.5 Feet (2m), Power Cord
PowerEdge Server FIPS TPM 2.0On-Board LOM 1GBE (Dual Port for Towers, Quad Port for Racks and Blades)Sliding Ready Rack Rail
RAID 5 for H730P/H730/H330 (3-8 HDDs)
PowerEdge R430/R530 Motherboard MLKPerformance BIOS Settings
3Yr ProSupport and Next Business Day On-Site Service

 

Je to ok?

[Max]

Pokud počítáš s využitím té cache na řadiči, tak nikde nevidím info o tom, jestli je součástí baterie k řadiči.
Pokud přemýšlíš o využití ZFS jako storage, tak je třeba počítat 1TB = minimálně 1GiB RAM. Tzn., že min 4GiB ram musíš dedikovat pro storage + zbytek musí utáhnout všechny ostatní služby (2GiB pro hypervisor + zbytek pro VM).
Jinak v tom problém nevidím.
Zdar Max

[R]

Pokial viem, tak DELL dodava cache vzdy s bateriou.

[chinook]

Díky za upozornění na RAM. Ještě nevím co aplikovat jako storage, přemýšlím na propojení přes DRBD v režimu Primary/secondary. Tedy na každém serveru bude k dispozici cca 1,7TB a tam nasadit BTRFS.

Případně co doporučuješ?

[Max]

Reálné zkušenosti mám s jiným provozem, takže ti nemohu doporučit nic.
Nicméně kdybychom to stavěl já, tak bych šel asi do drbd primary/secondary + btrfs.
Zdar Max

[Aleš Kapica]

Když jsem používal DRBD v režimu Primary/Primary, tak jsem měl Ocfs2. V režimu Primary/Secondary bylo nasazení Ocsf2 zbytečné, takže jsem pak místo toho nasadil Btrfs. Fungovalo to, akorát se připrav na to, že když tam toho budeš mít opravdu moc, tak se ti může stát že ti bude trvat nepříjemně dlouho remount.

[chinook]

Díky za info. Remount moc potřeba snad nebude. Jen ještě se úplně v BTRFS neorinetuji.

V současnosti to mám tak, že mám LVM na tom DRBD a pak zase LVM a pak třeba ext4. BTRFS nahrazuje i LVM? Nebo to mám poskládat LVM -> DRBD -> a LVM nebo BTRFS?

A je vhodné BTRFS i na databáze? Podle benchmarku co jsem čet, tak je pomalé.

[Aleš Kapica]

B je správně. Nejdřív LVM, nasekat oddíly, nad nimi DRBD a pak Btrfs. Na databáze se Btrfs nehodí protože COW, ale to se dá se pro jednotlivé soubory vypnout. Ovšem pro databáze je lepší udělat třeba samostatný DRBD oddíl s jiným FS. Není špatné použít ext3 a nebo to Ocfs2 které z ext3 vychází.

Je to zkrátka věc návrhu.

[Josef Kufner]

Docela bych uvažoval o virtualizaci, obzvlášť pokud máš čas si s tím pohrát. Postavit si takový malý privátní cloud, každou službu do svého kontejneru, a pokud jeden server padne, tak ji můžeš vcelku snadno přesunout na sousední železo.

Na VMware se vybodni. Nechceš plnou virtualizaci, chceš jen kontejner. Takže LXC nebo Systemd-nspawn na btrfs. Přínosem, krom snadného přenosu mezi fyzickými servery, je i možnost si snadno udělat snapshot a upgrade nanečisto.

Až systémy přeneseš na nové servery, ponechal bych staré servery jako offline zálohy. — Nainstalovat na ně aktuální systém, který by byl schopný hostovat kontejnery, a nechat si je pro srýčka příhodu či na experimentování.

[multi]

Vidim to stejne: kontejnerova virtualizace+btrfs

[dustin]

Podobným způsobem jsme konsolidovali několik starších fyzických serverů na jeden výkonný s hodně diskovými sloty. LXC kontejnery, v nich běží původní servery (jen s minimálními úpravami), původní disky (rooty i datové) se jen přesunuly do nového serveru. Poté už si člověk může disky měnit dle potřeby, hostitel běží na vlastních discích s raid1.

Nekonsolidoval bych takto firewall, aby zůstal funkční net i při vypnutém hlavním serveru a šlo třeba brouzdat při hledání případného problému.

Disky máme vytažené do samostatné krabice, do serveru připojené několika SFF8088 kabely a ve skladu je připravený záložní server. V případě poruchy stačí do záložního přehodit SAS řadiče (ty bychom teoreticky mohli dokoupit taky záložní, jsou za pakatel), zastrkat SFF8088 kabely a jede se dál.

[Max]

Souhlasím s předřečníky. Koupit dva nový stejný servery (tak výkonný, aby jeden utáhl všechno), rozjet virtualizaci a provozovat vše na KVM/Proxmox (u Free ESXi je problém s monitoringem aj. věcma).
Pole mít na serveru jedno, stejný pro všechny VM. Nemá cenu rozdělovat služby na konkrétní fyzické disky, protože tím i nevratně rozdělíš výkon, který by jsi jinak mohl sdílet a líp vychytávat špičky.
Pak už je na tobě, jak si to nastavíš, jestli půlku věcí budeš mít na jednom serveru a druhou půlku na druhém a syncovat to navzájem, nebo všechno budeš provozovat na jednom a plný výkon druhého budeš mít pro testování.

Takže ram by ti stačila 32GiB / server a pokud jde o disky, myslím si, že není problém, aby ti to všechno utáhlo 6x 1,2TB 10k SAS v RAID10 (= 3,6TB kapacita) / server v podání nějakého HW řadiče s BBWC. SSD je zbytečný.
Pokud by jsi si chtěl hrát, tak můžeš ušetřit na hw řadiči a nasadit třeba ZFS, které můžeš do budoucna potunit přihozením SSD disku na cache. Získáš tím rychlé snapshoty, podporu rychlé komprimace + můžeš dělat asynchronní sync na vzdálený server v rámci ZFS (zfs send/receive) každých 5min.
Další možností je btrfs.
Musíš se rozhodnout podle sebe a svých zkušeností.
Zdar Max
PS: Jinak řešit uložiště pomocí externího pole mi u dvou serverů přijde naprosto zbytečné plýtvání peněz.
PPS: mně běží 60 VM (Exchange 1TB - 350 users, FS a tuna dalších věcí) na 24x hdd na externím poli přes NFS (sice to je NetApp, ale dává to slušně)

[Josef Kufner]

Proč upřednostnit KVM před LXC z praktického hlediska? Teoreticky je to možnost různých operačních systémů (vč. jádra) vs. nižší režie lehkého kontejneru.

[little-drunk-jesus]

treba security - privilegovane lxc kontejnery je narocne zabezpecit (obecne s kontejnery je to problem) - hodne selinuxu, seccomp, dropovani prav - ne kazdy tyhle veci zna a umi zhodnotit dopady pro sve aplikace.

[chinook]

Takže RAID 10 6X 1.2TB disk SAS. Asi na tu DB bych dal 2x250SSD, ale to si ještě promyslím. Ještě mě napadlo na file server, který není vůbec vytížen nestačil by nějaký levný nas a ten připojit např. přes nfs k serveru? Myslím, že tam je zbytečné kupovat serverové disky, tam by se ušetřilo a místo toho bych koupil na DB SSD disky ať se to trochu pohne.

A na ten mikrotik jako FW máš jaký názor? Nebo mám koupit zlášť server, resp. použít ten co mně zbyde, nebo nějaký virtuál nebo ten kde poběží KVM? Osobně se přikláním k mikrotiku. Zatím mně nikdo neřek proč ne.

[Max]

Jak už jsem napsal, nejdřív bych začal tím, že bych si spočítal současné IOPs a podle toho nasizoval storage. Jako, pokud nemáš problémy s manama, tak ok, ssd se neztratí, ale počítej minimálně 2x Intel DC 3700 200GB = 2x 9000,-Kč bez DPH, což je shodná cena jako nějakého HP SAS 1,2TB 10k.
Jsi napsal, že potřebuješ 800GB postfix + 2TB FS + 40GB db, což zní easy pro 6x1,2TB v RAID10 nad HW řadičem s nějakou 2GiB BBWC (předpokládám, že app nad tou db není něco prasáckého + nepřistupuje na ní tisíc lidí). Pokud si myslíš, že si se SATA vystačíš, tak pak bych šel tedy cestou 4x2TB WD RE v RAID10 (4x 3000,-Kč bez DPH) + k tomu 2x Intel DC 3700 200GB na databázi (2x 9000,-).
Pokud chceš ušetřit, tak pak na záložním serveru ty ssd mít nemusíš a v případě chcípnutí prvního serveru by to prostě běželo na záložním dočasně pomaleji.
Jinak NAS bych do toho nepletl. Fakt bych to řešil dva servery s interním storage a nějakým druhem replikace mezi nimi (buď DRBD, nebo v rámci FS = ZFS / BTRFS).
Starý server bych pro routing nepoužíval. Je to prosté, moc žere. Pokud máš UPS (jako, že asi máš), tak by jsi si další spotřebou navíc zkracovat čas běhu bez proudu, navíc když nejde proud, nejde klima, rychleji roste teplota atd. Je to jedno s druhým. Minimalizovat spotřebu je vždy dobré.

Neznám tvou topologii sítě, takže nevím, kde ten fw chceš mít, ale pokud je to nějaký poslední hop do/z netu, tak proti mikrotiku nic nemám. Samozřejmě to můžeš řešit i v rámci VM na serveru (buď jednoduchá VM s debianem a iptables, nebo nějaké klikací řešení jako pfSense, nebo snad už i ten mikrotik myslím podporuje běh ve VM pod KVM). Musíš si ale představit různé scénáře, co se stane a co budeš muset udělat, když něco z toho padne, nebo když padne vše atd.
Zdar Max

[dustin]

V serverech na DB používáme Intely S3500 a drží výborně. Po 3 letech silné zátěže má nejmenší wearout 92% (ze šesti ks). Bohužel cenově se drží pořád stejně. IMO není do serveru S3700 podmínkou.

Na DB bych s kvalitním SSD neváhal, pořád bude mít řádově rychlejší přístup, než SAS pole ze šesti HDD.

[LKG]

Pozor na to, S3500 mě pěkně vypekl, je potřeba se nespoléhat na SMART jako takový, ale počítat s tím kolik do něj bylo napsáno a uvažovat DWPD. Ty disky vydrží přesně pětiletý ekvivalent, a bez varování se odporoučí do věčných lovišť. Takhle odešlo 18 disků plus/minus v rozmezí dnů (rozložená stejná zátěž). Po tom co jsem je vytrhal, tak jsem je projel Intelí utilitou, a ta ukázala že jsou v čudu až po tom, co jsem se na nich pokusil o secure erase.

[dustin]

Díky. Existuje nějaká utilitka, která by to zdiagnostikovala za chodu, něco ve smyslu smartctl?

[LKG]

Hlídám to podle Host_Writes_32MiB, např. disk co jsem pastnul má natočeno 441,5 dne, a zapsalo se do něj 140,284 TiB dat. Je to 200 GB model, a má 10 DWPD, čili pojme denně 1,819 TiB dat. Má teda natočeno jenom circa 77 denní ekvivalent, bez problémů tenhle workload přežije. Předtím tam byl právě S3500, ten má 0,35 DWPD, propsat se může 65,209 GiB dat/den. Natočil by tedy za 441,5 dne ekvivalent 2203 dne. Natočit ale může jenom 1825 dní (5 let). To by už asi ten disk byl buď po smrti, nebo umíral.

Škoda že už nemám ty vadné S3500.......

=== START OF INFORMATION SECTION ===
Model Family:     Intel DC S3700 Series SSDs
Device Model:     INTEL SSDSC2BA200G3
Serial Number:    xxxxxxxxxxxxxxxxxxxx
LU WWN Device Id: xxxxxxxxxxxxxxxxxx
Firmware Version: xxxxxxxx
User Capacity:    200 049 647 616 bytes [200 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 2.6, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Feb 26 14:47:36 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
.
.
.
.
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       10595
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       17
170 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       13
175 Power_Loss_Cap_Test     0x0033   100   100   010    Pre-fail  Always       -       262140002937
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Temperature_Case        0x0022   089   074   000    Old_age   Always       -       11 (Min/Max 10/27)
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       13
194 Temperature_Internal    0x0022   100   100   000    Old_age   Always       -       20
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       4596826
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       2150
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       36
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       635677
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   098   098   000    Old_age   Always       -       0
234 Thermal_Throttle        0x0032   100   100   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       4596826
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       2618012

[dustin]

Super, díky moc. Ten náš (300GB) má 170TBW, zatím ten nejvíc má 26TB, tak předpokládám ještě pár let vydrží...

[Ondro]

Neviem ci ten vypocet zivotnosti by isiel zapisat este komplikovanejsie/neprehladnejsie ako si ho zapisal ty. Prepocitavat to na dni je zbytocna komplikacia.

Jednoduchsi popis. 200GB disk ma vyrobcom garantovanu zivotnost(zaruku) 3.65 PB zapisanych dat. To tvoje SSD ma zapisanych 140TB(vycerpalo 4%). Do konca garantovanej zivotnosti ti zostava este zapisat 3.61TB(96%). SSD je v super stave a pri takejto zataziti vydrzi este peknych par rokov.

Parameter DWPD je len ilustrativne(marketingove) cislo o zaruke na dane SSD. Zaruka na dane SSD je bud 5 rokov alebo 3.65PB zapisanych dat. Plati to, co pride skor. Tych 3.65PB mozes zapisat za rok alebo za 10 rokov. Prelozene do zrozumitelnej reci - -ak sa SSD pokazi za menej ako 5 rokov a bude mat zapisanych viacej ako 3.65PB, tak ti ho nevyreklamuju. -ak sa pokazi pred zapisanim 3.65PB ale SSD ma viacej ako 5 rokov,tak ti ho tiez nevyreklamuju.

Zivotnost sa da kontrolovat aj pomocou Media_Wearout_Indicator parametra(podla mna lepsi parameter ukazujuci realnejsiu zostavajucu zivotnost ale zalezi od nastavenej firemnej politiky). Je to ukazovatel opotrebenia SSD, 100 = 100% zostavajuca zivotnost. Ak padne na nulu, tak SSD dosli rezervne bloky NAND flash pamete a blizi sa jeho koniec. SSD neumrie hned ako tento paramater padne na nulu, moze este smelo fungovat dalej niekedy este celkom slusnu dobu. Niektory vyrobcovia ale obmedzuju dalsie pouzivnaie takehoto SSD, ked padne tento parameter na nulu. Existuju na internete testy, kde taketo SSD fungovali dalej a bolo mozne na nich zapisat este dalsie TB dat.

Vysvetlenie Toto SSD ma fyzicku kapacitu 264GB, z toho 64GB je uzivatelsky nepristupna a je to ako rezerva/nahrada za poskodene bloky na predlzenie zivotnosti. Tento konkretny disk ma hodnotu tohto parametra na 98 takze podla toho sa da odhadnut, ze by mal vydrzat viacej ako vyrobca garantuje. Preco? Vycerapalo sa 4% garantovaneho objemu zapisu ale Media_Wearout_Indicator klesol len o 2% (zo 100 na 98).

Tiez by som si hladal aj parameter Power_Loss_Cap_Test (Power Loss Protection Failure), co je indikator funkcnosti ochrany proti strate dat. Toto SSD obsahuje kondezatory, ktore pri vypadku napajania maju zabezpecit bezpecne zapisanie dat z cache na disk.

Write endurance z Intel specifikacie S3700 SSD. 100GB: 1.83 PBW 200GB: 3.65 PBW 400GB: 7.30 PBW 800GB: 14.60 PBW

[Honza]

FW bych určitě nechal jako extra HW. Dávat ho ale na server (ať už nově koupený nebo ten tvůj starý) je blbost. Mikrotik je dobrá alternativa, stejně jako pfSense nebo OpenBSD. Malá "krabička" s malou spotřebou. Jestli chceš NAS jako extra HW a nepotřebuješ ho do racku, tak mrkni na HP Microserver. Dal bych na něj FreeNAS (ZFS) nebo Openmediavault a můžeš ho používat i pro zálohy. Pošťáka a DB na server jak píšou ostatní výše.

[LKG]

Já si nemůžu pomoct, ale jestli by někde mělo opodstatnění použít ZFS, tak tady. Minimum 4xHDD a 2xSSD, na HDD raidz2 data, na SSD zlog a l2arc, a jet to na ZFS. Když se to celé pořídí 2x, tak prakticky není možné přijít o data, máte navíc možnost perfektně zálohovat a snapshotovat. Když budete mít akceleraci těma SSD, tak to utáhne všechny ty služby s prstem v nose, ty mašiny můžou jet klidně v KVM virtuálech nebo v kontejnerech.

Provozuju takhle několik serverů, některé v dost brutal zátěži, a kdo jednou čuchne k ZFS, tak nechce jinak.

[Honza]

Souhlas.

[chinook]

Přemýšlím, že nejdříve pořídímt jen 4xHDD, jak tu někteří radí. Když využiji oba servery, tak to disky musí zvládnout. Otázkou je jak to replikovat a zda mít obojí master to master např. přes DRBD a GFS?

Takže pak by se využívaly prostředky obou serverů a v případě výpadku jednoho se služby přesunou na druhý a hold to pojede o malinko pomaleji.

[Max]

Někdo tu vzpomínal, že DRBD v režimu master-master nemusí být plně ok. Na clusterové systémy jako GlusreFS, Sheepdog, Ceph apod. je zase potřeba trochu více nodů než dva. Já to vidím buď na master-slave drbd, nebo na řešení formou FS (ZFS, nebo BTRFS).
Nebo kombinací DRBD+BTRFS nad tím jako je popsáno třeba zde : Manual HA Cluster with Linux Containers, DRBD and Btrfs.
Zdar Max

[Aleš Kapica]

O tom, že DRBD v režimu primary/primary není zrovna dobrý nápad, jsem ti říkal nejspíš já. Na dva nody bych použil GlusterFS.

[glusterfs]

Na GlusterFS se dvěma nody bych raději zapoměl.

Simulace - odpojen první nod.

Druhý nod sám od sebe umřel v řádu desítek minut. Bylo sice možné ho ručně nahodit, ale ...

[Aleš Kapica]

Záleží na co to chceš, jak to je nakonfigurované a co to je za hardware.

[ZS-Man]

Primary/Primary DRBD8 mam na jednom 2node clusteru (Proxmox) a bez problemu. Jen je nutne mit VM disky jako WriteTrought nebo DirectSync. Treba WriteBack je problem a hrozi poskozeni tech VM disku. Prezilo to par osklivych vypadku el. (problem s UPS) a zatim vse OK, vlastne se o to temer nestaram. Ale s tim jednim 2node clusterem nejsem moc reprezentativni vzorek, moznam mam jenom (zatim) stesti.... :)

Trochu horsi je to ted s DRBD9, Linbit udelal chvilkovy zmatek s licenci drbdmanage, Proxmox ho vyhodil z repo. Linbit ma sice vlastni repo primo pro Proxmox, ale ta situace je takova nemastna neslana.... Az se konecne dostanu k aktualizaci toho Proxmoxu, tak asi pujdu do GlusterFS.

[chinook]

S master master filesystémem nemám zkušenosti. Zatím všude provozuji DRBD PRIMARY/SECONDARY. Nechce se mně dělit to pole na půlky a na jednom serveru by běžely nějaké nody a nadruhém jiné nody. Asi nejjednodušší řešení, ale budu mít rozdělené pole napůl.

Se systémy ZFS a BTRFS nemám zkušenosti a i když jsem googlil, nepochopil jsem jak by výsledné pole vypadalo. Když bych měl kapacit 3,6GB, tak by se na obou serverch mohlo využívat společný prostor 3,6GB pro oba nebo bych měl režim primary to secondary, takže na každém bych měl kapacitu jen 1,8GB?

Lepší mně přijde, že bych měl společné pole 3.6GB a já si libovolně přesouval virtuální machiny ze serveru na server.

A nemusel bych mít vše nakonfigurováno 2x chápu, že dovecot, ldap, postgresql atd. zvládají replikaci sami, ale musím každou změnu konfigurovat 2x. Ideální by bylo mít jeden stroj kde běží třeba dovecot. Odejde jeden node, jen spustím stroj na druhým nodu.

Nebo mně něco uniká a dělá se to úplně jinak? Chci mít pak co nejjednodušší zprávu.

A taky čím servery propojit kvůli replikaci? 10GB síťovka? Nebo jak se to dělá?

[Max]

Já mám v jobu 3 nadupaný servery připojený ke storage a do sítě jako takové přes 2x10Gbit síťovku. Storage mám do sítě připojen také přes 2x10Gbit síťovku. Storage mám namapován přes NFS a síť to stíhá úplně v klidu. Jak už jsem napsal, 60VM, jak 1,5TB Exchange, tak 1TB FS, 1TB Kerio, 800GB SAP (OracleDB), 600GB MSSQL atd. Storage je velký 30TB a dělám nad jeho částí snapshoty a posílám to na vzdálený storage + přes snapshoty dělám backup VM.
Já mám ale Netapp + ESXi + Veeam.
Každopádně si myslím, že by to v tvém případě neměl být problém syncovat přes 1Gbit síťovku. Nicméně spousta dnešních serverů má už v sobě 10Gbit síťovku a byla by škoda toho nevyužít.
Zdar Max

[dustin]

Máme DRBD propojené standardním gigabitem dedikovaným jen pro dané DRBD (kabel napřímo, bez switche) a běží to úplně v pohodě. Gigabitem se protlačí trvale 100MB/s.

S tou správou máš samozřejmě pravdu, čím složitější, tím komplikovanější. Mirrorujeme přes drbd filesystém LXC kontejneru s rozchozenými službami a pak jej na druhé straně stačí jen namontovat a spustit, samozřejmě po převzetí IP adres. Nedovedu si představit, že bych měl udržovat (aktualizovat, měnit konfigurace) dva živé filesystémy.

DB (mysql, mongo) jedou přes master/slave replikaci. Jednak jsem je chtěl mít hot, jednak např. mongodb potřebuje alespoň 3 uzly, tak tohle je hned jeden z nich. Tam mi údržba nevadí, protože se na nich skoro nic nemění.

[chinook]

Takže máš DRBD Primary/secondary. Např. si pole rozdělím napůl a na každém nodu bude běžet jedna půlka a tam virt. mašinky? V případě poruchy, jen tu druhou půlku přemantuju a spustím na druhém nodu?

Dále píšete, že stačí 1GB síťovka, v současnosti to mám taky, tak, ale nedávno jsem nad tím přemýšlel a i jeden disk už zvládne 150MBps. Nebude lepší propojit servery 10GB síťovkou a pak tam dát třeba 3x1gpbs do síťe?

[dustin]

Takže máš DRBD Primary/secondary. Např. si pole rozdělím napůl a na každém nodu bude běžet jedna půlka a tam virt. mašinky? V případě poruchy, jen tu druhou půlku přemantuju a spustím na druhém nodu?

Třeba tak. My máme jeden stroj výrazně silnější, tak na něm běží vše (je to i tak rychlejší), záložní se fláká (ale má konfiguraci dostatečnou na rozumný běh všeho).

Zase je dobré to moc nepřekomplikovat, každý úkon navíc při failoveru bolí... Dříve jsme měli failover automatizovaný, ale to mi nevyhovovalo, raději to přehodím ručně (samozřejmě připraveným skriptem).

Dále píšete, že stačí 1GB síťovka, v současnosti to mám taky, tak, ale nedávno jsem nad tím přemýšlel a i jeden disk už zvládne 150MBps. Nebude lepší propojit servery 10GB síťovkou a pak tam dát třeba 3x1gpbs do síťe?

Jasně že to špičkový výkon nepřenese, ale opravdu máš na tom poli stálou zátěž > 100MB/s, aby to nestíhalo? Jinak samozřejmě ten 10gigabit tam dát můžeš, zase tolik nestojí.

Nám to na HDD filesystémy stačí, zase tolik změn tam není, a databáze na SSDčkách jedou přes replikaci.

[dustin]

master/master drbd bych se bál použít. Ani master/master db bych nepoužil. Když už tak master-write/slave-read, ale to komplikuje aplikaci.

Pokud si můžeš dovolit výpadek do zásahu admina (IMO to pro vnitrofiremní služby může (ale taky nemusí) stačit), dal bych disky ven, aby je šlo snadno kabely přepnout do záložního stroje a přehodil bych to v případě problému ručně. Stačí jen přehodit IP adresy, nastartovat pole a kontejnery a jede se dál.

Pokud ne, pak bych volil duplicitní HW i s disky (nouzový sekundár může mít třeba trochu míň paměti/CPU, HW dnes nic nestojí), db bych mirroroval master/slave replikací nebo clusterem a filesystémy drbd master/slave. Stačí pak jen přehodit drbd a IP adresy a nastartovat kontejnery. Nevýhodou je vyšší spotřeba - běží servery dva.

Failover je třeba u obou variant mít otestovaný, ale to je samozřejmé.

[Josef Kufner]

Určitě bych nechal databázi, ať si to replikuje sama. Bude na to mít spolehlivější nástroje a bude tam o vrstvu k rozbití méně.

Jinak nějakou inspiraci můžeš čerpat u Gitlabu, v issue trackeru věnovanému infrastruktuře.

[R]

Akurat robim dva servery pre mail/groupware cluster a snazim sa vyhnut replikacii na urovni filesystemu.

Replikaciu mailov by mal zvladnut samotny dovecot (dsync). Replikaciu databazy (MariaDB) riesi Galera cluster, v Debiane 9 su uz baliky.

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář