Delame servery, jak to v enterprise nenajdete - dil II.

17.3.2013 14:42 | Přečteno: 5857× | vpsFree.cz |

Tentokrat vam popisu, k jake serverove konfiguraci jsme nakonec dospeli a proc, jake kupujeme disky a co si myslim o centralnich diskovych ulozistich.

Uz nebudeme troskarit - dvouprocesorove systemy s dostatkem RAM

Minuly rok, kdyz nam akorat dochazela volna kapacita vsech twinu i toweru dohromady, dorazila na trh platforma Supermicro X9 pro nejnovejsi Intel Sandy Bridge Xeony. Musel jsem mit aspon jeden, chtel jsem to zkusit .

Pri takove velikosti (vpsFree melo cca 300-350 VPS celkem) uz jsme si mohli takovou masinku dovolit. Specifikace jsou nasledujici:

• 2x Intel Xeon E5-2630 (6ti jadro, 15MB L3, 2.3GHz)
• 128 GB DDR3 ECC RAM - tohle mne prekvapilo, jak je i ECC RAM levna - dneska vsehovsudy 2500 Kc za 16GB DDR3 modul.
• 6x 1 TB HDD
• 2x 240 GB SSD
• Za 128 tisic penez s DPH

Na takovou masinu jsme mohli hned konsolidovat 3 towery. Sranda je, ze ve finale je to pro jednotlivou VPS jeste vyhodnejsi, protoze cim vetsi rozdil je mezi velikosti jedne VPS a celkovou velikosti HW, kde bezi, tim vetsi sance je, ze se HW prostredky budou dat bezbolestne agregovat (dulezite klicove slovo pro rejpaly: bezbolestna agregace = nikomu nikdy nevadi a neprijde do cesty).

V tuhle chvili, kdy jsme takovy server koupili a nasadili do provozu, vysel na Root.cz clanek o vpsFree, diky kteremu jsme rapidne narostli - tim myslim +100 clenu behem jedineho mesice, ja osobne to povazuju pri beznem prumeru 10 za mesic za obrovsky uspech . Takze bylo potreba koupit dalsi takovy.

Kupujeme Fat Twin

Jelikoz se dvouprocesorova sestava osvedcila a diky tomu ^ narustu v poctu clenu se nam podstatne zvetsil rozpocet na hardware, jsme se rozhodli zahajit migraci vsech VPS na takovy hardware. A v tu chvili opet prislo Supermicro s genialni platformou - Fat Twin. Narozdil od klasickych twinu, ktere bezne proste nemaji tolik pozic na disky a trpi jejich upgradovatelnost, 4-nodova verze Fat Twinu obsahne uplne presne to same v jednom nodu, jake jsme zacali stavet ty dve predchozi masiny - 8 disku, 2CPU, 16 DIMM a i nejake to PCIe se tam v pripade potreby vejde.

Vsechny VPS v Praze uz mame dneska tedy na tomhle hardwaru, uz bych si to celkem nedovedl predstavit jinak. Ceka nas jeste Brno, to bychom meli resit pravdepodobne ke konci roku.

Dilema s diskovym IO

Kdyz se nasklada 80 VPS na jeden node, zacina byt trochu problem stihat obslouzit vsechny jejich IO pozadavky - i kdyz s 240 GB Flashcache je to mnohem, mnohem mensi problem, nez by byl bez ni, porad se obcas muze stat, ze ve spicce proste disky nebudou stihat.

(Poznamecka: ano, 80 VPS na jeden node - to je proste krasa kontejnerove virtualizace - nicmene o softwarove strance se rozepisu nekdy priste).

Warning: ted si zacpete oci vsichni vyznavaci "enterprise", jinak vam z nich zacne krvacet

Kaslu na "enterprise" HDD! Nevyplati se. Tecka. Kupujeme Western Digital Caviar Black Edition uz od prvnich mesicu existence vpsFree.cz - jedinou vyjimkou byly 1U twin nody, tam byla Raid edition (RE2, RE3 a po vymene nektere RE4). Mezi RE a Black disky je naprosto minimalni rozdil. Deal with it. Za tu dobu, co tyvsechny masiny provozujeme, v prepoctu na typ podle kusu mame priblizne stejnou umrtnost mezi ruznymi modely disku RE a Blacky - dokonce mozna RE maji procentualne vetsi umrtnost.

V pripade RE disku si tak clovek priplaci za "dobry pocit", to je asi tak vsechno. Mam podezreni, ze RE a Black jsou ty same disky s trochu jinym firmware (RE maji TLER - ale who cares, Linux mdraid to stejne neumi vyuzit).

Stejne tak kaslu na hardwarovy RAID! Zkousel jsem ruzne radice (LSI, Areca), verte nebo ne, softwarovy RAID v pripade RAID10, RAID5 i RAID6 umi byt na soucasnych x86 CPU rychlejsi. A ze nam RAID sezere kousek jednoho jadra CPU, nas netrapi. HW RAID je prezitek, vhodny tak pro systemy, ktere SW RAID neumi, nebo ho umi jeste hur nez linux. Delal jsem mereni a porovnavani na Illumosu se ZFS (raid-z, raid-z2, raid-z3), na RHELu s mdraidem (5, 6, 10) a ve vetsine pripadu SW RAID je rychlejsi, nebo stejne rychly, jako HW.

Kvuli zmatkovani s hardwarem a hlavne softwarovou konfiguraci (zkuste efektivne spravovat 24TB storage pod linuxem...) se nam nedochovaly vysledky benchmarku, coz me dost stve a dava to memu tvrzeni mensi vahu, ale co se da delat, zkuste si to sami (idealne pod realnou zatezi, ne syntetickymi benchmarky), pokud neverite.

A tak v poslednich dnech premyslim, jestli by nestalo za ty penize, zkusit koupit masinku s 12ti 2.5" pozicemi a dat do nich 2.5" Scorpio Black (a 2 SSDcka). Stejne budeme muset dokoupit nejaky ten hardware brzo, tak to vyzkousime. Slibuju si od toho vetsi IOPS, protoze vic mensich disku rychlejc odbavuje IO queue.

Centralni diskova pole

Zalezi na use-case, nekde davaji smysl, nekde ne. Podle meho, davat VPS na diskove pole muze byt fajn, ale spatne se skaluje. Kdyz mate 4 virtualizacni nody, kdyz jich je 8, nebo i 20, daji se obslouzit jednim rozumnym polem. Vezmete si ale nekolik racku masin a zkuste centralizovat uloziste... Dobre, tohle se nedela, pro dalsi racky se koupi separatni uloziste. Ale v cem je pak ta vyhoda centralizovane spravy uloziste?

Krome toho, centralizovanim uloziste stavite do systemu vyrazny SPOF. Jasne, da se pouzit vic frontendu k jednomu diskovemu poli, coz vyzaduje SAS disky, ale cena to takoveho reseni podle meho nazoru vyrazne prevysuje vyhody centralizovaneho uloziste. Nehlede na fakt, ze je malo open-source vyvojaru, kteri vyviji primo nad SANem, takze je nutne pouzivat jenom takovy software, ktery prochazi poradnym QA zahrnujicim i takove use-cases.

Delat SAN po Ethernetu je docela smrt, iSCSI je podle mne sprosta nadavka, kterou vymyslel nekdo, kdo se chtel pomstit koncovym uzivatelum dat nad tim protokolem. Takze zbyva FibreChannel, InfiniBand a jine low-latency high-bandwidth SAN reseni.

V tom momente, kdy mame SAN, je pri kontejnerove virtualizaci potreba pouzit clusterovy filesystem, kdyz maji data jedne VPS byt dostupne na vice nodech zaroven (pro snadne balancovani, servisovani jednotlivych virtualizacnich nodu a podobne). NFS jde pouzit akorat do verze 3, protoze jsou potreba syrova nemapovana UID/GID vlastniku souboru, coz s NFSv4 udelat nejde. S NFSv3 prijde omezeni maximalne 16ti sekundarnich skupin, v kterych muze jeden uzivatel byt, aby UGO opravneni fungovala korektne, navic v3 nezna ACL, coz povazuju za vyrazne omezeni.

Ve vpsFree centralni uloziste nachazi vyuziti tedy hlavne na zalohovani, ktere zas v kontrastu podle mne nedava smysl ukladat lokalne. Dalsim vyuzitim bude v blizke budoucnosti NAS pro mene vyuzivana data hlavne pro lidi, kteri si chteji do vpsFree posilat domaci zalohy a pro podobne skladovaci use-cases.

Dalsi strankou centralnich ulozist je fakt, ze nemam rad proprietarni reseni. Prijde mi omezujici, abych si na poli, ktere stejne vetsinou skryva nejakou x86 platformu pod kapotou, nemohl bezet nejaky nas backend, pripadne napriklad slave MySQL instance pro replikaci a nasledne snazsi zalohovani bez ovlivneni chodu masteru.

Jenze postavit pole na Linuxu tak, aby bylo stejne flexibilni, jako single purpose storage boxy napriklad od NetAppu, je temer nadlidsky ukol. Tohle jsem v poslednich mesicich vyresil nasazovanim OpenIndiany na zalohovaci storage, kdo nepouzival ZFS v takove skale (aktualne 24TB syroveho mista, neco okolo 600 datasetu, nad kazdym 14 snapshotu), poradne nepochopi, o cem mluvim. BTRFS je proti nemu fajn hracka, ale takovemu nasazeni je jeste na mile daleko.

Nevyhodou OpenIndiany jsou bugy v jejich verzi Illumosu a hlavne absence stabilniho release - tohle clovek musi holt vyresit vlastnim buildem a investici nejakeho casu do takoveho reseni. Na druhou stranu, v Solaris ekosystemu se takova prace snadno recykluje a je pak nasaditelna snadno na vice systemech.

Vim, ze i FreeBSD ma podporu ZFS, ale tam chybi poradna integrace s NFS, navic FreeBSD 9.1-RELEASE se ukazalo zabugovanejsi, nez Illumos

Pro prostredi, kde jsou na to penize, myslim neni 1000 USD na socket rocne za licenci Solarisu 11 takova prekazka. Jak jsem ale rekl, proprietarnimu reseni nefandim, takze Solaris nechavam jenom jako nejposlednejsi zachrannou cestu, kdyby se Illumos ukazal dlouhodobe jako nepouzitelny - za tech par mesicu, co nam Illumos bezi, to zatm nevypada jako realna "hrozba".

O ZFS, OpenIndiane a buildeni Illumosu se zrejme rozepisu v blizke budoucnosti, protoze to podle mne stoji za podeleni se .

V pristim poslednim dilu tehle serie o hardwaru zbyva rozebrat, jak resime sitovou infrastrukturu

       

Komentáře

[Miloš Kozák]

Hezký zápisek, nepochopil jsem jen tu část s centrálním úložištěm. Používáte centrální úložiště nebo ne? Vzhledem k tomu, že máte více nodů, jak bez centrálního úložiště dostáváte ty VPS na jednotlivé nody? Hlavně jak získáváte aktuální stav při výpadku nodu... Dík

[snajpa]

Centralni storage nepouzivame. VPS jsou ulozene lokalne, vypadek nodu - zalezi, jestli je volny hardware, nebo ne. Dneska vetsinou mame jeden cely volny node, takze se jednoduse precvaknou disky a jede se dal. Driv jsme to museli resit obnovou zalohy (ktera se dela kazdou noc).

[Miloš Kozák]

Takže to jinými slovy znamená, že ta VPS prostě nejede a může jich být až 80. Lidi jsou s tímto v pohodě? Stalo se to již někdy? Zvládne SW raid zamíchání HDD?

[snajpa]

Zamichani disku mdraid zvladne. Navic v datacentru je 24/7 support, takze vypadek to bude na par desitek minut, coz se muze stat vsude a i pri jinych situacich, nez jenom hw chybach. Stalo se nam, ze nam v RAID10 ze ctyr disku umrely dva disky zrovna do krize (jeste v jednom z toweru, kde ty disky byly prehrate), takze jsme museli obnovovat data ze zaloh. Jelikoz v tu dobu byly zalohy pres rdiff-backup, ktery je proste nechutne pomaly, trvala obnova celkem 5 hodin, nastesti to ale bylo v noci.
Nastesti mame VPS zalohovane jednou denne, takze ztrata dat neni tak bolestiva. Muj nazor je takovy, ze je to dostacujici uroven dostupnosti a kdo potrebuje vyssi, muze si vzit dve VPS ve dvou lokacich a redundanci resit na aplikacni vrstve - redundance se totiz vzdycky resi nejlip prave na aplikacni vrstve, protoze tam jsou nejlepsi informace, co ma a nema byt redundantni.

[Ondrej 'SanTiago' Zajicek]

Navic v datacentru je 24/7 support, takze vypadek to bude na par desitek minut, coz se muze stat vsude a i pri jinych situacich, nez jenom hw chybach.

Neexistuje neco, co by umoznilo provozovat clusterove reseni jednoduse bez nutnosti centralniho uloziste? Napr. mit sparovane nody a v kazdem paru provozovat DRBD (nebo neco podobneho) tak, ze pulka VPS bezi primarne na jednom a druha pulka na druhem nodu, ale je mozne okamzite premigrovat/prevzit na druhy nod. je pri vypadku jednoho nodu. (Nejspis by pak slo i omezit redundanci v ramci jenoho nodu.)

[ewew]

Neviem či by to malo zmysel, pretože vpsfree.cz nemá žiadne dohodnuté SLA. Prípadne ma opravte.

[snajpa]

Oficialne je vpsfree "best effort", ale myslim si, ze v porovnani s poskytovateli v CR bychom si stali dost slusne. Nekdo by takovou statistiku mohl udelat, mohlo by to byt zajimave. Pro zajimavost statistiky na monitoring-serveru.cz - dostupnost http vpsfree.cz, dostupnost ping ns1.vpsfree.cz, dostupnost ping ns2.vpsfree.cz - kde v lednu jsme delali rosady s internimi sluzbami, tak jsme tam spadli pod 99.8%.

[snajpa]

Takove napady uz byly, vetsinou to zakapalo na tom, ze jak se prida do toho storage stacku neco podobneho, tak je storage najednou globalne min spolehlivy, nez klasicky lokalni bez replikace. Navic, konkretne DRBD je v upstream kernel az od 2.6.33, kdezto OpenVZ/RHEL6 kernel stavi nad 2.6.32, takze tam ani DRBD neni.

[Als]

DRDB pro standardni centos/rhel kernely je v centosplus repozitari. A taky je na tohle dobry glusterfs.

[snajpa]

Ktery je uzasne stabilni s vysokou propustnosti :) Tohle uz jsem si prosel, dekuji, nechci - malem mi pri vsazeni na takovehle pseudotechnologie umrela firma.

[Als]

Jo s glusterfs mam podobne a pomerne cerstve zkusenosti :) Ale, kdyz to Red Hat prodava, tak resim jestli to jen neni PEBKAC :)

[Als]

Stejne, ale to FUSE se mi pochopitelne moc nelibi, takze nyni testuji ZFS on linux.

[SPM]

Těch lidí, co to nasadili jako storage pro vm a pak brečí, že nemaj výkon (v lepším případě) je v mailing listu poměrně hromada :) Osobně mám gluster nasazený na storage pro zálohy a nějaké další takové věci - tam mi přijde docela fajn. Ale udělat z toho storage pro virtuály, na to bych koule teda neměl :)

[Aleš Kapica]

Existuje. Třeba sheepdog.

[Radek Podgorny]

...a cim delate backupy ted, kdyz uz ne rdiff-backupem? dik!

[snajpa]

rsync na ZFS + snapshoty :)

[snajpa]

Btw, porad lepsi situace, kdyz nejde 80 VPS kvuli umrti lokalniho kusu hardwaru, nez kdyz jich nejde 500+ kvuli umrti centralniho storage - coz je stejne pravdepodobna situace. Tim spis, pokud prosazujeme staveni reseni nad open-source (= komercni appliance nepripadaji v uvahu). To je ostatne jeden z hlavnich duvodu, proc centralni storage nemame a jen tak mit nebudeme.

[Miloš Kozák]

Ahoj, samozřejmě souhlasím. Nicméně jak jsi psal jsem use-cases..... Zkoušeli jste nebo přemýšleli nad tím koupit 2x něco co by mohlo fungovat jako centrální storage a přes ZFS to exportovat do jednotlivých nodů? A samozřejmě pod tím vším nechat běžet něco jako je drbd a pacemaker, čímž byste docíli toho, že má centrální storage, výhody ZFS a nakonec ještě fault tolerance?

(já se v této oblasti tak moc neorientuji, takže nevím co openindiance/solaris nabízí pro online replikaci a zda je možné nad tím vším mít ještě ZFS, vše ostatní se dá přes pacemaker krásně pořešit na linuxu)

[snajpa]

ZFS ma send/receive, coz po seskripteni rekl bych nahradi asynchronni variantu DRBD. Nad ZFS jdeme realizovat NAS pripojovany do VPS, takze uvidime, jak se tomu bude darit a podle toho mozna prehodnotim svuj postoj k centralnim ulozistim.

[Miloš Kozák]

Ono právě-že potřebuješ synchronní zápis, aby ses mohl bránil proti SPFO. Na linuxu se prostě použije DRBD a export pomocí NFS/iSCSI/AOE, ale ZFS by tam prostě vypadalo lépe, proto to píši :D

[snajpa]

Prusvih je, ze v podstate krome iSCSI uz neni moc moznosti, jak ten storage exportovat - NFS pro rootfs VPS nejde (viz clanek), export blokoveho zarizeni zas maze vetsinu vyhod ZFS, navic v nasem setupu nuti pouzit clusterovacich FS, ktere jsou jedna velka tragedie :(

[Miloš Kozák]

Souhlas a to vaše openvz neumí mít rootfs v nějakém datablocku? Pokud to jde a z toho co píšeš, by to mělo jít.. tak nad tím iscsi můžeš rozjet LVM a jednotlivé LV budou root disky VPS.. já to takto mám s KVM a funguje to velmi dobře, navíc se tím vyhneš použití cluster fs...

[snajpa]

V poslednich verzich OpenVZ se objevil PLoop, coz je block device a nad nim Ext FS, jenze tim se ztraci flexibilita - mit moznost runtime zavolat

vzctl set [veid] --diskspace 100GB

a hned tim zmenit kvotu pro VPS je proste luxus, navic to jde nahoru i dolu za behu VPS.

[sigma]

Zajímavé čtení. Hlavně ta OpenIndiana.

U centrálního úložiště záleží, co je v daném prostředí akceptovatelné, a co ne. Jestli je akceptovatelné riziko, že při havárii jednoho serveru odejde pár disků, a tím přijdeme o data vytvořená od poslední zálohy. Jestli je akceptovatelný čas, než někdo přendá disky do rezervního HW. Jestli je akceptovatelná závislost na jedné lokalitě.

U centrálního storage pro takové prostředí samozřejmě uvažuju synchronní replikaci a multipath propojení. Takže žádný SPOF. A vyhodnocení výhodnosti ceny takového řešení se odvíjí od předchozího odstavce.

K tomu HW RAIDu - pokud máte něco jako flashcache v roli write-back cache, tak už je na tom SW RAID docela dobře. Třeba některé operace na Postgresql trvají bez RAIDu s writeback cache i 20 × déle (protože se pořád čeká na flush). Jinak je to o přístupu, jestli víc věřím flashcache v kernelu, nebo podobné funkcionalitě na HW kartě / SAN řešení. S těmi testy výkonu je to těžké, hlavně ale praxe ukazuje, že je nesmysl porovnávat výkon v sekvenčním čtení jednoho nebo několika málo streamů, protože to obvykle není typická zátěž.

Máte na těch samotných HDD povolený writeback? Pokud ano, tak při výpadku napájení se ty data z diskové cache nenávratně ztratí. Opět záleží, jestli je to akceptovatelné nebo ne.

[alkoholik]

Co se tyka spolehlivosti disku, tak u nas odesel jeden v NetAppu a v EMC zadny.
Cetl jste nekdy, jak EMC testuje disky? To nejsou obycejne prebrandovane. NetApp do nich sype i vlastni firmware.
Na druhou stranu jsme slysel, ze NetApp je postaveny na FreeBSD a ZFS.

[snajpa]

FreeBSD je pravda, ZFS ne, maji vlastni FS.

[ee]

wafl

[Käyttäjä 11133]

FreeBSD je pravda, ZFS ne, maji vlastni FS.

Nechť NetApp není Data ONTAP C-mode, pak neplatí ani jedno. Nebo... je v tom případě je i Windows založené na FreeBSD protože mají jejich TCP/IP stack.

[Käyttäjä 11133]

To nejsou obycejne prebrandovane. NetApp do nich sype i vlastni firmware.

Vlastní firmware na NetApp discích je hlavně kvůli znemožnění použití běžných Seagate disků v úložišti, za účelem zachování marže z prodeje SupportEdge podpory pro diskové shelfy.

[kolcon]

co je spatneho na iscsi?

[Franta]

+1

[Program]

Žere volný datový tok?

[Käyttäjä 11133]

A FC ho na té SANce nežere?

[Käyttäjä 11133]

Zalezi na use-case, nekde davaji smysl, nekde ne. Podle meho, davat VPS na diskove pole muze byt fajn, ale spatne se skaluje. Kdyz mate 4 virtualizacni nody, kdyz jich je 8, nebo i 20, daji se obslouzit jednim rozumnym polem. Vezmete si ale nekolik racku masin a zkuste centralizovat uloziste... Dobre, tohle se nedela, pro dalsi racky se koupi separatni uloziste. Ale v cem je pak ta vyhoda centralizovane spravy uloziste?

FAS 6240 - 250 039,67 IOPS na 189TB použitelné kapacity. To je poměrně hodně racků s hosty pro virtuální mašiny.

Jasne, da se pouzit vic frontendu k jednomu diskovemu poli, coz vyzaduje SAS disky, ale cena to takoveho reseni podle meho nazoru vyrazne prevysuje vyhody centralizovaneho uloziste.

Doplň si základní vzdělání.

Nehlede na fakt, ze je malo open-source vyvojaru, kteri vyviji primo nad SANem, takze je nutne pouzivat jenom takovy software, ktery prochazi poradnym QA zahrnujicim i takove use-cases.

Centralizované uložiště nemusí být SAN, nehledě na to, že Linuxové FC SAN drivery jsou velice pěkně odladěné a pro aplikaci se to chová jako lokální disk (nechť Oracle ASM a podobné nejsou aplikací).

Delat SAN po Ethernetu je docela smrt, iSCSI je podle mne sprosta nadavka, kterou vymyslel nekdo, kdo se chtel pomstit koncovym uzivatelum dat nad tim protokolem. Takze zbyva FibreChannel, InfiniBand a jine low-latency high-bandwidth SAN reseni.

iSCSI je na tom moc hezky po 10Gb/s Ethernetu a se switchi od Dellu je to i celkem levná záležitost, když už chceš hovořit o desítkách racků.

[snajpa]

Marek Stopka saves the day! Yay! Ale co jsem tim chtel rict, nepochopil.

[Käyttäjä 11133]

Třeba pochopil, "but does not give a shit". :)

[snajpa]

Pak je ovsem vsecko v poradku.

[snajpa]

Btw, ted seriozne, abych mel trochu prehled - kdybych chtel storage system od NetAppu s neco okolo 24TB mista a tak 10k IOPS, dualhead, co by mne to vyslo a jaky model vybrat?

[Käyttäjä 11133]

Pošli "ofiko" poptávku na marek.stopka@perlur.cz a cena bude obchodnímu tajemství dle § 17 zákona č. 513/1991 Sb., obchodní zákoník. Tohle už je custom konfigurace, kterou jen tak na web hodit nemůžu...

Nicméně 8160 IOPS na 450GB SASech je 2x DS2246-1011-24S-QS-R5 + F2240A-2-24X450-R5. Což je v listovkách 132 565 USD. Ale na skutečnou cenu je potřeba opravdu mít poptávku. Takhle malou konfiguraci jsem nikdy necenil, ale minimálně u větších konfigurací je sleva 60 - 80%.

[Mrkva]

No nevím nakolik u vpsFree s obchodním tajemstvím pochodíš. To se stydíš na web napsat kolik za to chceš? Já bych ti na to řekl "nasrat". :D

[Käyttäjä 11133]

Pochodím s ním úplně stejně jako u jakékoli jiné právnické osoby se sídlem na území ČR? Navíc jak jsem již uvedl, já nevím kolik za to chci...

[Mrkva]

No, členy bude skoro určitě zajímat, kam jdou jejich členské příspěvky :) A troufám si tvrdit, že v libovolném sdružení pokud předseda/rada prohlásí něco ve stylu "sorry, obchodní tajemství, co je vám po tom?" tak hodně rychle skončí.

[Käyttäjä 11133]

Tak si přečti co znamená obchodní tajemství a jaké má právní důsledky a vůči komu je má...

[Mrkva]

No, mě jde o to, že jelikož ty evidentně považuješ cenovou nabídku za obchodní tajemství... WTF? seriózní firma snad zveřejní kolik chce za co někde na webu, aby měl zákazník porovnání s konkurencí, ne? Oh wait, my se pohybujeme v "enterprise sféře"... Ok, zpátky k tématu.

Ty považuješ cenovou nabídku za obchodní tajemství. Náhodou se snajpa zblázní a přistoupí na to. Samozřejmě po něm budu na členské schůzi zdůvodnit proč má najednou sdružení dluh 2.5 mega. Buď to zdůvodní, a pak o tom bude vědět třeba 50 přítomných - v té chvíli i když to někdo vynese ven tak nezjistíš kdo. Nebo to nezdůvodní a pak při nejbližší příležitosti navrhnu jeho odvolání :)

[Käyttäjä 11133]

Buď to zdůvodní, a pak o tom bude vědět třeba 50 přítomných - v té chvíli i když to někdo vynese ven tak nezjistíš kdo.

Proč bych já zjišťoval kdo to vynesl, když to můžou za mě dělat orgány činné v trestním řízení?

[Mrkva]

Tak ono je jedno kdo to nezjistí. Jestli ty, nebo OČTŘ.

[kolcon]

je dobre vedet, kdo svym (potencialnim) obchodnim partnerum vyhrozuje, jeste nez k nejakemu obchodu dojde...

[pavlix]

+1

[Käyttäjä 11133]

Vyhrožuje... heh, s tím to nemá nic společného, mnohem víc to má společného s našimi smluvními závazky, neboť tím že jsme se stali partnery nějaké společnosti jsme se taky zavázali například k tomu, že budeme ctít cenovou politiku té společnosti a budeme jednat v souladu s jejich zásadami pro cenové nabídky.

Mi je samozřejmě jedno, co by se s tou nabídkou stalo, ale prostě ty ceny jsou neveřejné a já s tím nic nenadělám. A legal disclaimer není vyhrožování, je to tzv. ochrana zadnice.

[Franta]

Jsem sám komu se nelíbí tohle obchodování jak někde u stánkaře v Turecku? Mobilními tarify to začíná a šmelením s hardwarem zdaleka nekončí. Na tohle říkám jedině: nasrat. Ať obchodník vyloží karty na stůl a já si vyberu, co mi přijde nejvýhodnější. Ne že se budu s někým pokoutně dohadovat.

[Cubic]

Me osobne je to taky proti srsti, ale skoro zadna vetsi firma ti ceny za hardware nebo sluzby nezvereni na internetu a skoro stejne mnozstvi ti ji nepovi ani po telefonu. Pokud se ti to nelibi tak s tim nic nenadelas, neni kam jinam jit. Na druhou stranu to znamena, ze se s cenou da skoro vzdy zahybat. Zrovna netapp nam uz dostkrat slevil, a to tak ze ostatni vyrobci to proste po par vyjednavacich telefonatech zabalily s tim, ze by nas dotovali z vlastniho kdyby chteli srazit cenu nas stejnou uroven. Opravdu jak na bazaru...

[Franta]

Me osobne je to taky proti srsti, ale skoro zadna vetsi firma ti ceny za hardware nebo sluzby nezvereni na internetu a skoro stejne mnozstvi ti ji nepovi ani po telefonu.

U individuálních služeb je to normální – taky jako dodavatel neříkám předem cenu, protože to nejde odhadnout, nebo se lidi minou v očekáváních a neví, za co ta cena je, tak jim to přijde moc drahé nebo naopak OK, ale pak toho budou chtít víc, než jsem chtěl dodat… tam se cena dohodne až po důkladných konzultacích.

Jenže tohle není případ komoditního zboží a typických služeb, které se sekají jak Baťa cvičky.

ostatni vyrobci to proste po par vyjednavacich telefonatech zabalily s tim, ze by nas dotovali z vlastniho kdyby chteli srazit cenu nas stejnou uroven. Opravdu jak na bazaru...

Někdy si říkám, že je to takhle zařízené kvůli lidem, kteří neumí nic jiného než mlít pantem – aby si taky mohli připadat úspěšní a důležití, že něčeho dosáhli, získali slevu… Jsou to takové virtuální hodnoty pro potěchu těch, kteří by jinak reálně žádné hodnoty nepřinesli. Bez tohoto handlování bychom se mohli bavit věcně, o technických a obchodních výhodách daného řešení. Ne řešit, jak máš náš nákupčí nejlépe podkuřovat zástupci dodavatele na golfu, aby ukecal lepší cenu.

[trekker.dk]

No, mě jde o to, že jelikož ty evidentně považuješ cenovou nabídku za obchodní tajemství... WTF? seriózní firma snad zveřejní kolik chce za co někde na webu, aby měl zákazník porovnání s konkurencí, ne?

Kdyť jsi to sám napsal o něco níž. Katalogové ceny jsou přepálené (protože co kdyby to někdo, čti státní úřady, za ty peníze náhodou koupil), takže se dávají "slevy". No a tu cenu se slevou přece nevyvěsíš někam na web, to by další zákazníci začali vyjednávat o ceně na téhle hodnotě a ne na té přestřelené...

[snajpa]

Wow, no to mam pocit ze i se Sun/Oracle HW a Solaris 11 + ZFS to porad postavim levneji a stejne to mam se supportem

[Käyttäjä 11133]

Chceš tam 10GbE, nebo 8Gb FC SAN? Nebo ti budou stačit 8x (4x na řadič) 1GbE?

[snajpa]

4GE je celkem OK na ten pripadny usecase (nejde o vpsFree, tam o podobne vylomeniny nikdo nestoji...), rekl bych.

[Käyttäjä 11133]

Support? 3 years NBD, 5 years NBD, nebo něco více fancy jako je 24x7 4 hours?

[snajpa]

Asi to presuneme na mail? Napisu ti.

[Mrkva]

Takhle malou konfiguraci jsem nikdy necenil, ale minimálně u větších konfigurací je sleva 60 - 80%.

To si i tady musíme hrát na divadlo se "slevami", které vlastně slevy nejsou? To je jak na nákupu v Mountfieldu. Přiznej barvu a řekni spíš, že tabulkové ceny jsou o takových 60-80% přepáleny oproti cenám za které se to opravdu prodává. A jelikož musíte i tak mít nějaké zisky, tipuju že dalších pár procent bude marže a skutečné náklady budou tak do 10k USD. Jdu blejt, velebnosti.

[pavlix]

Přiznej barvu a řekni spíš, že tabulkové ceny jsou o takových 60-80% přepáleny oproti cenám za které se to opravdu prodává.

Bacha na různé základy procent.

[SPM]

Však to taky za tabulkové ceny nikdo nikdy nekupuje :)

[kyytaM]

Ale kupuje. Statna sprava uplne standartne.

[Käyttäjä 11133]

Ne, tam se k listovce ještě nabalí 10% premium .

[SPM]

ok, oprava: nikdo normální to za tyhle ceny nekupuje :)

[Bystroushaak]

Pošli "ofiko" poptávku na marek.stopka@perlur.cz a cena bude obchodnímu tajemství dle § 17 zákona č. 513/1991 Sb., obchodní zákoník. Tohle už je custom konfigurace, kterou jen tak na web hodit nemůžu...

Jen čistě ze zvědavosti - jakou má tohle logiku? Protože i když jsem se snažil, žádnou jsem za tím nezahlédl.

[Käyttäjä 11133]

To je snad dobře, když politika toho výrobce je taková, že konečné ceny jsou neveřejné, ne?

[Bystroushaak]

Dobře? .. Dobře je silně subjektivní slovo. Proč by to pro mě mělo být dobře?

Proč by vůbec obecně něco tak podstatného, jako cena zboží měla být neveřejná? Já to fakt nechápu.

[Käyttäjä 11133]

Proč? Nevím jak u zboží, to přímo nevyrábíme, ale u služeb máme listovou cenu, a různé skutečné ceny pro různé zákazníky. A občas jdeme s cenou i pod skutečné náklady, protože ten jeden konkrétní projekt nám otevře dveře k tomu zákazníkovi. A jak by to asi vypadalo, kdyby všichni naši zákazníci věděli že jsme někomu prodali poradenství za tak nízkou sumu? Chtěli by to taky a mi bychom pak skončili velice rychle v konkurzu.

Třeba jeden z našich zákazníků má smluvně domluvenou slevu 50% na všechny služby v prvních 2 letech projektu. Což už je pod mzdové náklady po započítání rizikové marže a cestovních nákladů, ale teď jim děláme nabídku na jiný projekt a tam už je ta sleva menší a bude tam i nějaká marže. Kdybychom neudělali ten první obchod, tak by nás s žádostí o nabídku na ten druhý těžko oslovili. Tak třeba proto jsou skutečné ceny součástí obchodního tajemství.

[trekker.dk]

Ve zkratce: děláte něco, za co by vás mohl někdo klepnout přes prsty. Žádné překvapení.

[Käyttäjä 11133]

Nemohl, protože naše riziková marže není prokazatelným způsobilým nákladem a tudíž se nejedná o dumpingové ceny z pohledu právních norem. Stejně jako u případného soudního řízení bychom snadno argumentovali tím, že dlouhodobě očekáváme vyšší utilizaci lidských a jiných zdrojů.

To máš jako tvrdit, že když postavíš nové datové centrum, tak by si na začátku životního cyklu měl těm 2 zákazníkům co máš účtovat celý overhead napájecí a chladíci soustavy. Tak se to prostě nedělá, spočítáš si náklady na nějakou cílovou utilizaci (střední hodnotu v rámci životního cyklu datového centra), k ní přibalíš nějaká rizika a nějakou marži a pak za to prodáváš. I když máš dlouhodobě při té nižší utilizaci ztrátu, tak se jí snažíš z pohledu cash flow nějak uřídit a "doufáš" že utilizace zdrojů poroste tak, aby ses k té plánované dostal co nejdříve.

[trekker.dk]

klepnout přes prsty != že by vám to nakonec dokázali. Pravděpodobně nedokázali.

To máš jako tvrdit, že když postavíš nové datové centrum, tak by si na začátku životního cyklu měl těm 2 zákazníkům co máš účtovat celý overhead napájecí a chladíci soustavy.

Špatný příklad. U datového centra počítám s větším počtem zákazníků a tak těm prvním účtuju jenom to, co na ně připadá (zbytek jde na vrub mně, protože tam zatím mám prázdný prostor.) Dumpingová cena pro jednoho zákazníka s tím, že tomu samému zákazníkovi následně prodám něco dráž, je něco jiného.

[Käyttäjä 11133]

To je úplně stejný příklad jako s tím datacentrem. Když děláš u zákazníka poradenství, tak na začátku životního cyklu projektu děláš spoustu věcí delší dobu, než se s tím prostředím seznámíš a vypracuješ rozumnou dokumentaci k tomu prostředí od které se dá odpíchnout.

Vzhledem k tomu, že si účtuješ za MD, tak na začátku dáš nižší cenu za MD a později v rámci životního cyklu toho projektu tu cenu navyšuješ, protože dostane výstup v té samé kvalitě za kratší čas. Tu slevou v podstatě jen odrážíš to, že fakturuješ v čase a přitom by se mělo fakturovat za úkol. Ale těžko budeš 5 letý projekt fakturovat za úkol, že "až skončí životní cyklus té platformy tak vám to vyfakturujeme", protože bychom to prostě finančně neuměli uřídit a zároveň se ten projekt nedá rozdělit do tak mnoha krátkých fází, abychom mohli fakturovat třeba co 3 měsíce. Takže se raději dohodneme na fakturaci měsíční za odpracovaný čas a ten GAP se vykryje právě tou slevou, která stoupá každý rok o 10 procent.

[petr_p]

A přitom by to mělo být obráceně. První služba dražší, protože má dodavatel více práce se seznámením se s prostředím, a pak již levněji, protože má menší práci.

V podstatě se snažíte první podhodnocenou službu zajistit odběr dalších služeb. Kdyby tato snaha byla zhmotněna do něčeho jiného než jen víry, tak by se na to dal napasovat nějaký protikorupční zákon (Američani jich znají velké množství).

Tady je krásně vidět, jak je tenká hranice mezi tržním a korupčním jednáním.

[xkucf03]

Tady je krásně vidět, jak je tenká hranice mezi tržním a korupčním jednáním.

Ta hranice je jasná a toto není případ korupce. Korupce je, když uplácíš někoho, aby zneužil své pravomoci a přihrál ti něco z majetku, který aktuálně spravuje (ale nepatří mu). Můžeš tedy uplatit politika nebo manažera tím, že jim osobně poskytneš nějakou výhodu a oni pak poškodí svého zaměstnavatele (stát, firma…), který z tebou poskytnuté výhody nic nemá.

Jenže, když poskytneš slevu zákazníkovi (jako celé právnické osobě, ne konkrétnímu manažerovi) a od té samé právnické osoby očekáváš v budoucnu další zakázky, tak to nemůže být korupce. (byť to může být něco taky velmi nepěkného – ve spojení s dalšími praktikami)

[petr_p]

Já jsem nepsal, že to je korupce.

Jen mi přijde od zákazníka hloupé, aby skočil po očividně (očividnost se právě snaží dodavatelé schovat do obchodního tajemství) dotované nabídce a pak musel krvavě platit za následné služby. Pokud to udělá nevědomky, tak by ho akcionáři měli rychle vyměnit. Pokud to udělá vědomě, tak je třeba se ptát, co z toho má, protože přesně takové chování je projevem korupce. A jediný rozdíl pak je, jestli se korupce prokáže, nebo ne, což v případě, že obě strany mlčí (a ještě jim nahrává institut obchodního tajemství) je značně problematické.

[vencour]

Pokud to udělá vědomě, tak je třeba se ptát, co z toho má, protože přesně takové chování je projevem korupce. A jediný rozdíl pak je, jestli se korupce prokáže, nebo ne, což v případě, že obě strany mlčí (a ještě jim nahrává institut obchodního tajemství) je značně problematické.

Jak pozoruju, nikde nejde jen o jednu část ekosystému, patří k tomu zachování poskytovaných služeb a dohodnutých smluv. Ono se dost těžko přechází jinam nebo na něco jiného.

[Franta]

A občas jdeme s cenou i pod skutečné náklady, protože ten jeden konkrétní projekt nám otevře dveře k tomu zákazníkovi.

To je právě praktika, která se mi nelíbí – tvářit se, že je něco levné nebo dokonce zadarmo a když na to zákazník skočí a stane se závislým, tak ho oškubat. Podobně to dělají drogoví dealeři…

[kyytaM]

Rozumiem myslienke, ale nie je to vzdy take jedoznacne - zakaznik zaplati bez problemov aj viac, ked ma istotu, ze praca bude dobre vykonana - co bez predchadzajucich skusentosti nebude vediet. :)

[Dundee5]

Tohle je naprosto běžná praxe, dělají to "všechny" firmy i ty velmi slušné.

[Franta]

Dělat to férově je ale dlouhodobě neudržitelné – pokud tam není vendor lock-in, co brání zákazníkovi si při příští zakázce vybrat třeba diskové pole od jiného výrobce? Zákazník se chová přirozeně tržně a pokud mu někdo jiný nabídne ekvivalentní produkt za nižší cenu, tak koupí od něj – nebude od tebe draze kupovat, jen proto, že jsi fajn a dal jsi mu kdysi slevu, nebo že jste kamarádi.

Takže v důsledku tahle cenová politika implikuje neférové obchodní praktiky: ošidit zákazníka, namluvit mu, že je to levné/zadarmo a pak, když už nemůže couvnout, ho oškubat.

[Käyttäjä 11133]

Pokud tam není vendor lock-in, co brání zákazníkovi si při příští zakázce vybrat třeba diskové pole od jiného výrobce?

To že se to třeba nevyplatí? Protože když pořídíš nějakou technologii tak jí upravíš nástroje, nakoupíš integrační nástroje, imlementuješ monitoring, vyškolíš lidi. A to vše je náklad, který plánuješ nějakou dobu odepisovat, když změníš dodavatele diskových úložišť, tak musíš všechny tyhle investice udělat znova. A to stojí peníze, a rozdíl v těch cenách mezi jednotlivými výrobci je tak malý, že se zřídka kdy vyplatí. To už se spíš mnohem častěji implementují dual-vendor politiky, kdy celou dobu kupuješ od obou výrobců, a máš procesy,... přizpůsobeny technologiím obou výrobců.

[Franta]

To že se to třeba nevyplatí?

A jak bys definoval vendor lock-in? Např. Wikipedia ho popisuje takto:

In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

S čímž se celkem ztotožňuji. Vždy je to o nákladech, které je potřeba vynaložit na přechod jinam – závislost na MS Windows je podobná – není to nic nemožného, jsou to „jen“ náklady na přepsání softwaru, aby nepoužíval proprietární funkce, a přeškolení lidí.

[Mrkva]

Doplň si základní vzdělání.

Tohle jsem tu dlouho neslyšel :D

[Käyttäjä 11133]

No co, já myslel, že SATA2SAS bridge jsou stará známá technologie. A NL-SAS je taky někde jinde cenově, než SAS.

[SPM]

Switch od Dellu? To je zase nějaký rebrandovaný edgecore? :))

[kyytaM]

Dell nedavno kupil Force10. :)

[dizz.]

Muzu se zeptat proc pouzivate WD Caviar Black kdyz Barracudy 7200.14 by meli dosahovat podobnych/stejnych vysledku pri nisi cene? Je v tom jen ze mate lepsi zkusenost s WD nebo nejaky parametr ktery neni ve vecine testu vzan v potaz?

Planuji nakup dvou disku do RAIDU (na takove to domaci virtualizovani) a hledam nejvhodnejsi kombinaci.

Diky

[snajpa]

Dlouhodobe kdykoliv jsme koupili neco jineho nez WD, tak se to sypalo. Naposled jsme do pole kupovali nejakych 8ks 3TB Seagate a z toho 2 kusy odesly behem prvnich dvou mesicu.

[ewew]

Ako riešite likvidáciu poškodených a nefunkčných HDD ?

[anonym]

Co jsem slysel tak minimálne jednou si vyrazené disky odnesl nekdo ze clenu domu. takze asi tak.

[snajpa]

Vetsinou je premazeme a rozdame mezi aktivni cleny, kteri maji root access tak jako tak (takze neresime premazavani na milionkrat a podobne).

[Pavel Siska]

Jaké jsou výhody, nebo rozdíl čtyřnodového 4U FatTwin oproti 4x 1U ve stejné konfiguraci v případě kdy stačí 4 disky na node? Cenově mi přijde FatTwin dražší zhruba o 8000 Kč na node ve stejné konfiguraci.

[snajpa]

Odpovedel sis v otazce :) My potrebujeme 6 3.5" disku a 2 2.5" SSD, coz do 1U nenacpeme. Dalsi vyhodou je mensi spotreba ventilatoru, protoze v 1U ty ventilatory zakonite zerou vic, jelikoz jedou na vyssich otackach.

[bibri]

Hezké čtení a hezká diskuse - jen tak dál :).. Máme podobné požadavky, teda až na objem dat (stovky TB, letos asi PB).

Dotaz - proč ne glusterfs?

[snajpa]

Pokud nebudes mit hromadu nodu (vic nez par jednotek), tak je to pomale. K tomu se pridava jeste dost nepekna nestabilita. Kdyz budes verit, ze tu nestabilitu casem odladi, tak pak ber jako dobrou radu, ze Glusterem nema cenu spravovat soubory mensi nez 1MB, jinak je to silene pomale.

[bibri]

Dík za info, menší než 1MB určitě ne, vidím to tak >1GB :). IOPsy mne zatím tolik netíží, tíží mne objem dat a v té souvislosti taky cena komerčních "enterprise" řešení :).

Ještě jeden dotaz - fakt by se nenašly ty testy rychlosti softwarového raidu? Jak spojíte 16 nebo 32 disků do raidu - máte přídavné SAS/SATA řadiče? Nevyjde to ve finále dráž?

S těmi RE/Black disky je to zajímavý postřeh, nicméně to si asi nedovolím, i když nejsem úplně klasický vyznavač "enterprise"....

[snajpa]

Hledal jsem ty testy, fakt to nemuzu najit, museli jsme to zapomenout odzalohovat mezi jednotlivymi reinstalacemi toho pole

Jinak co se tyce 'spojovani' - 8 disku navesime v pohode, ty desky maji 2x SATA3 a minimalne 6x SATA2, vetsi pocet disku se resi SAS expandery primo v backplane - coz ta masina "2node v 2U s 12ti 2.5 disky per node" ma, dokonce ma i SAS2 HBA onboard.

[Nikola Ciprich]

RE maji TLER - ale who cares, Linux mdraid to stejne neumi vyuzit

- HE? co konkrétně neumí využít? toto je podle mně právě stěžejní důvod proč POUŽÍVAT RE disky namísto běžných (a jednou jsme se pěkne spálili s RE disky kde TLER nefungoval kvůli chybě firmware...).. ani nemusím být enterprise fanatik abych trochu kroutil hlavou...

[kyytaM]

+1

[chsajarsa]

Delat SAN po Ethernetu je docela smrt, iSCSI je podle mne sprosta nadavka, kterou vymyslel nekdo, kdo se chtel pomstit koncovym uzivatelum dat nad tim protokolem.

Ono se take doporucuje, pokud to clovek mysli s iSCSI vazne, tak ji stavet jako SAN. Tedy separatni switche a cela infratruktura, pokud mozno to neroutovat a povolit Jumbo frame. Super je take pouzit hw iSCSI karty.

Jeste bych zkusil FCoE. To je take pomerne zajimavy protokol.

Vyhoda tech enterprise storage je hlavne managementu monitoringu a funkcich co ten storage nabizi. Souhlasim, ze pro VPS hosting to nema cenu, ale kdo to zkusim a muze porovnat, tak uz nechce jinak . Managovat storage pro 200 serveru nebo dokonce pro tisice(pokud to neni nejake unifikovane reseni) proste jednoduseji nejde.

Mimochodem, kdy bude dalsi VPSFree hospoda?