Dotaz: Doporučíte PDU do racku? Nebo jak řešit zkrat?

[Max]

Ahoj,
řekněme, že máme nějakou běžnou strukturku, kde jsou dvě UPS a na ně jsou z racku napojený PDU. Ty jsou pak různě rozházený, je to manuálně rozbalancovaný atd. Pokud použijeme obyčejné PDU, tak v případě zkratu (třeba vadný zdroj ve switchi) dojde ke shození ochrany UPS na konkrétním power outletu a tím padne všechno, co je na tom výstupu připojený a nemá to druhý zdroj s připojením na jiný outlet.
Otázkou je, zda se tomu lze nějak bránit? Existuje třeba nějaký dobrý PDU do racku, který má ochranu na jednotlivých zásuvkách a když na nějaké z nich dojde k přetížení nebo zkratu, tak jí odpojí a nepadne tak celý PDU?

Běžným PDU je myšleno něco jako toto: PremiumCord PDU 19" 1U, 8x230V 16A
Vyloženě po ePDU nebažím, spíše mně zajímá, jak se vyvarovat podobným problémům.
Nemáte někdo nějaký tip jak to řešit?
Díky
Zdar Max

Odpovědi

[Jendа]

Zrovna řeším ten stejný problém! Moje první naivní řešení bylo koupit super rychlej jistič a doufat, že vypadne dřív než upstream. Ale nefunguje to, protože při zapojení zdroje se nabíjí kondíky a tenhle jistič vypadne. Už jsem taky přemýšlel o žárovkovém softstartu, ale je to samozřejmě na nic.

[Max]

Já rozhodil sítě všude možně, tak snad najdu řešení. Díval jsem se na chytré ePDU, které mají na sobě skupiny, které jsou asi chráněny zvlášť, ale nevím nevím. Raději bych narazil na někoho, kdo to řešil, nebo se s řešením setkal.
Zdar Max

[Jendа]

Včera mi na bastlírně doporučili softstart (v podstatě termistor a relé, které ho přemostí až se kondíky nabijou).

[R]

Riesenie je mat vsetky zariadenia s dvoma zdrojmi, kazdy zapojeny do inej vetvy. Zariadenia len s jednym zdrojom zapojit aspon cez automaticky prepinac.

Vyriesit to nejako inak je dost problem. Aj doma ked sa "vydari" poriadny skrat, tak vyletia vsetky istice cestou az po hlavny.

[Max]

To právě že ne. Pokud připojíš zařízení přes automatický přepínač, tak ti vadný zdroj sundá jednu větev, přepínač to přepne na druhou a tu to také schodí. Tj. je to v mém příkladu horší řešení, než to nechat prostě na jedné větvi.
Zdar Max

[trekker.dk]

Co jistič na každou zásuvku? A teda doufat, že vybaví i v případě, že vám ten zkrat jednu větev sundá - tj. dřív, než vám sundá i tu druhou.

[Max]

Tím jističem myslíš co? Výchozím bodem je vždy nějaké PDU, což je hafec zásuvek vedle sebe. Před PDU je pak jistič výstupu té UPS.
Takže myslíš něco nainstalovat mezi PDU a koncové zařízení? Něco jako ty velké zásuvky s přepěťovou ochranou? Pokud ano, tak ale co? Všechno je obří, nejlépe, kdyby to bylo součástí PDU.
Zdar Max

[trekker.dk]

Jističem jsem měl na mysli zařízení, které bude mít nezávisle jištěnou každou zásuvku. Jestli to bude PDU s hafcem jištěných zásuvek, nebo kabel se zástrčkou na jednom konci, zásuvkou na druhém a jistič mezi tím, to už je jedno - prostě něco, co se pokusí odpojit postižené (zkratující) zařízení tak, aby ten automatický přepínač mohl přepnout na druhou napájecí větev a nevyrazil ji taky.

Jestli se to vyrábí, s tím bohužel nepomůžu.

A jak jsem psal, i tak budete muset doufat, že vyletí jen to, co chcete.

[R]

Lenze aky istic tam das? 6A? To na velky server stacit nebude. A 10A vyleti aj s nadradenym istenim.

Priklad z praxe: skrat v zdroji, vyletel 16A istic zasuvkoveho okruhu aj 25A bytovy. Poistka F8A v zdroji, za ktorou bol skrat, prezila.

[Max]

Pokud mám mluvit za sebe, tak servery neřeším, tam jsou všude dva fyzické zdroje, vše odděleno, hotplug apod. Řeším routery a switche. Na druhou stranu, PoE switch o plném osazení může mít klidně i 200W, ale běžnější je něco slabšího.
Zdar Max

[R]

Na maly switch mozes skusit istic 2A alebo 4A - len nie je iste, ci nevypadne pri pripojeni zdroja.

[Heron]

Routery a switche se dají zapojit tak, že výpadek jednoho z nich nevadí.

Také jsem se na počátku (cca 2010) divil, proč má všechno dva zdroje a switche jen jeden, ale potom mi síťař ukázal, jak se síťuje (minimálně dva switche, každý server připojit minimálně jedním utp do každého ze switchů). Výpadek switche potom neznamená vůbec nic, jede se ze záložního (záložních). Pochopitelně je nutné mít správně nastaveno (R)STP a novější protokoly. Standard je dva kablíky v nějaké redundanci do každého switche - potom nevadí výpadek síťovky, portu na switchi, ani výpadek celého switche.

U routerů je to složitější, ale řešení též existuje. Routery mohou sdílet IP (tedy default gateway pro servery) pomocí protokolu HSRP a v případě výpadku jednoho z nich to potom převezme druhý router.

Nejsem síťař, nevím, jak se nastavuje složitější síť s mnoha cyklickými cestami, ale tohle se běžně používá a dává to smysl. Switch je potom spotřebák, který se vyměňuje kus za kus.

Takže než vymýšlet nějaké elektrické udělátko, šel bych touhle cestou. Je to redundantní i z hlediska jiných aspektů, než jen výpadek napájení jedné větve.

[Max]

Všechno popsané vím a mám to tak uděláno, ale né úplně vše. To je důvod, proč řeším otázky typu:
Vyplatí se toto předělávat a mít to robustně i na síťové vrstvě, nebo výpadek jednou za x let na 20min nevadí?
Musím to hned na všech úrovních řešit robustně, nebo půjde nějak minimalizovat popsané riziko na straně napájení?

Osobně jsem podobný incident zažil poprvé, většinou totiž když mi něco odešlo z těch kvalitnějších věcí, tak to bylo tak, že to prostě umřelo :-/

Každopádně někteří místní by ti řekli, že řešit failover pomocí RSTP je out of date, protože dnes existují řešení, které splní jak failover, tak mají oproti RSTP možnost využívat všechny trasy (LACP, IRF apod.) U routerů se dost často pro ten základ používá VRRP.
U L3 switche ale na VRRP lze zapomenout. Takže u něj se musí řešit failover pomocí stacku, tj. mít stackovatelný L3 switch a všechno do něj mít zapojeno do aspoň dvou node pomocí trunku nebo lacpu.

Pokud jde o výměnu switche, tak to nebývá moc jednoduchá akce, resp. záleží na několika faktorech. Téměř vždy to obnáší nějaký druh přednastavení (v případě stacku definování čísla stacku + portů pro cluster komuniaci, v případě normálního switche obnovu nastavení ze zálohy). Pokud jsou na switchích vlany, tak jsou tři možnosti výměny:
1) když není místo v racku, tak popsat si všechny zapojené kabely (třeba 48ks), vyměnit switch a znovu zapojit na porty, kde byly
2) když je místo v racku, tak nainstalovat switch pod současný a přepíchat kabely
3) pokud máme rozjetý 802.1x s automatickou konfigurací portů, tak opět easy a nic se neřeší, protože je vesměs jedno, co kam píchnu.
4) pokud chvátáme, máme vlany, nemáme místo v racku ani automatickou konfiguraci portů, tak to risknout, zapojit podobně a pak řešit nefunkční věci

Já osobně mám 10Gbit switche ve stacku, všechny servery připojený přes 4x10Gbit (2x10Gbit pro storage a 2x10Gbit pro app/hypervisory/zálohování/user access).
Zdar Max

[Heron]

Osobně jsem podobný incident zažil poprvé,

Chápu, ono to chce dlouhodobější statistiky. U mě je to jednoznačné, většina výpadků byla způsobena protivýpadkovým systémem. V racku máme dvě napájecí větve. Kolega si prosadil JEDNU UPSku pro zálohování jedné větve. Druhá byla napojená přímo na DC. A hádej, se kterou větví byl největší problém? USP se rozhodla zkontrolovat aku, aku chcíplo a ta zálohovaná větev spadla. Byla tam většina síťových prvků. Ve výsledku je lepší se na USP v racku vyprdnout, nebo mít dvě fakt dobré a fakt pravidelně udržované (měnit aku po x letech a nečekat, až se jejich parametry zhorší - stojí to pochopitelně dost peněz). Obecně čím méně prvků, tím lépe. O napájení se stará DC, nemusím to řešit. A mám další historky, jak "redundantní" věc způsobila více problémů, než kdyby to prostě bylo single.

Selektivita jističů je vždy komplikovaná věc. Impedance sítě je pod 1ohm (často třeba 0,2ohm), takže při zkratu tečou stovky ampér. Jistič neomezuje proud, pouze vypíná. A když máš za sebou 6A, 10A, 16A, 25A, tak při zkratu vypadnou všechny. Proto se často používají pojistky, protože než se ten drátek přepálí, chvilku to trvá. Jistič je mnohem rychlejší (při zkratu). Takže vhodně navrženými pojistkami selektivitu dosáhnout lze. (Ale musí to navrhnout zkušený projektant, řešilo se to roky na elektrika.cz.)

Co se týče síťování, tak díky za info, nejsem sítař, psal jsem info z roku 2010. VRRP jsem testoval pro použití s GlusterFS. Fungovalo to, ale pro produkční nasazení jsme nakonec použili něco jiného (zcela jiný storage).

Já osobně mám 10Gbit switche ve stacku, všechny servery připojený přes 4x10Gbit (2x10Gbit pro storage a 2x10Gbit pro app/hypervisory/zálohování/user access).

Jo, tohle je rozumné řešení. Na tohle jsme přecházeli někdy kolem 2016. S tím, že pouze dva kabely z jednoho serveru a rozdělení na jednotlivé role se řešilo až pomocí VLAN. Tohle tehdy někomu přišlo jako lepší řešení a ušetřilo se za Xkrát 10GbE síťovky. Fungovalo to spolehlivě.

Výměna switche je hlavně o fyzické práci. Konfigurace se nalije ze zálohy a potom jen přepojit porty do správných vlan skupin.

[Max]

Já měl do té doby také jen 2x 10Gbit. Problémů je více. Zaprvé se vždy tradovalo, že se cesta ke storage nemá trunkovat, jelikož to přidává nějaké latence. Další problém je, že ESXi vyžaduje pro iSCSI sólo síťovky. Takže před hafec lety (rok 2014?) jsem měl nasazený 2x10Gbit a používal jsem NFS4.1 proti NetAppu. Po 5 letech nový storage, který NFS neuměl, takže iSCSI a 2 porty u každého serveru navíc.
Ale není to reálně nic proti ničemu, jelikož se tím zlepší i rychlost aplikačního zálohování.
Zdar Max

[Heron]

Zaprvé se vždy tradovalo, že se cesta ke storage nemá trunkovat, jelikož to přidává nějaké latence.

Storage bylo připojeno primárně přes sas kabel redundantně přímo do diskového pole. iSCSI byla záložní varianta. A opět, přepnutí ze sas komunikace na iSCSI naprosto bez výpadku. Takto upgradovali firmware v těch řadičích a rebootovali je. Za běhu.

Jinak máš pravdu, ten sas byl rychlejší než běh po iscsi. To tam bylo opravdu jen jako záložní varianta připojení storage.

A ono, když už máš v serveru 2x10GbE síťovky + 2xsas řadič, tak tam dávat ještě další 2x 10GbE pro storage už je trochu moc. V našem případě se volilo trunkování a VLAN pro storage, management a produkční přístup na vmka. Funkční řešení a i ten storage přes to šlapal.

[Max]

Jinak dodám, že jedu 10kVA UPSky (dva plné racky baterií v každé lokalitě) a je to úplně o něčem jiném, než klasické UPS. Pokud máš někde tu klasiku jako APC SMT1500RMI2UC, tak u takových se odporoučely baterie a šlo to celé ze dne na den do kopru, i když předchozí dny procházely testy za jedna.
U těchto velkých vypadá to řešení nesmrtelně a když se něco stane, mění se jen 4U packy baterií. Zatím jsem nezažil, že by pack odešel. Každopádně instalace takových UPS lze provádět jen někde, protože mají přes tunu na docela malém prostoru :).
Zdar Max

[R]

Pozor, aj velka a draha UPS dokaze umriet. Osobne vyskusane na francuzskom smejde Infosec. 10kVA, 3-fazovy vstup. Francuzi do tejto drahej bedne dali najlacnejsie kondenzatory Jamicon TK, ktore vyschli. Mal som to rozobrate a rozchodil som to.

[Heron]

Jo, to prostě nepochopíš. Ať si to dávaj do customer věcí (nebo ať si to strčí někam), ale do profi výrobku? Já s rád rozdělávám staré věci a prostě všude jsou nippon chemicon případně pro audio věci rubycony. To je radost pohledět. A potom ti přijde do ruky šmejd, kde jsou capy na 80°C a 1000h shelf life. Tohle byl extrém. Oprava za běžně dostupné panasonic za hoďku a ten monitor někde funguje dodnes (pro zobrazování dokumentů a běžnou kancl činnost bohatě stačí).

[j]

Cemu nerozumis? Kdyz milonkrat useris hovno, muzes pohnojit cely pole ... ;D

V lete sme deckam ukazovali jehlickovou tiskarnu. Fungovala. Uplne vpohode. Uvnitr paradni frezovany ocelovy prevody. Vedle v kanclu je tiskana za 1/2M ... a cely to je srackoidni plast, a za ty prachy to ma odezvu jak 286 ktera napozadi pocita let na mesic a zaroven atomovou bombu. Bez servisni smlouvy to pak praticky nemuzes provozovat, protoze se to sere setrvale(a ne, vymena vyrobce nepomuze, vsude je to stejny, spis jeste horsi), a plastovy kolecko v nakladech za 10 haliru stoji litr.

Kdyz dam dneska auto do servisu a chci standardni veci (volej, filtry ...) tak se me ptaj, jestli jim tam to auto s praci na 1/2 hodiny necham 2 dny. By se z toho clovek posral ...

---

Dete s tim guuglem dopice!

[R]

Monitorov som opravil niekolko stoviek. Pouzivame DELLy. Takmer vsetko kondenzatory. Obcas nejake CCFL trubice. Nastastie tam este nie je LED podsvietenie - to je pricina cislo 1 problemov pri televizoroch.

[j]

;D ... videl sem (a pres par zdi slysel) UPSku (6kVA) prakticky vybouchnout ... :D. Jestli si nekdy byl fakt blizko strilejiciho kanonu, tak se to tomu dost blizi. Elektronika (celej plosnak) se prakticky vyparila. Baterky zustaly pokupe, ale samo na vyrazeni.

A jinak tuny per m2 resim celkem pravidelne, protoze on nalozenej rack kolem ty tuny vazi i bez baterek. Trebas disky taky nejsou zadny pericko. Ta zminena UPSka ma jen s internima baterkama tusim kolem 60kg. O to tragictejsi je, kdyz pak clovek prijde do novyho baraku, a soudruh architekt se strasne divi, kdyz mu reknu, ze potrebuju aby ta podlaha unesla 2t/m aby to melo nejakou rezervu.

---

Dete s tim guuglem dopice!

[R]

Toto ma zakladny battery pack, kde je 20 beznych baterii 12V 7Ah alebo 9Ah. To je 40kg baterii + ta plechova bedna. V samotnej UPS baterie nie su. Akurat som objednaval 40 baterii, v dvoch UPS totiz dozili. Kurier ma tie male 20kg krabicky velmi "rad" :D

[Max]

Ještě dodám ke Keepalived, že toto není opravdu komplexní řešení a nepokrývá to moc scénářů. Jde tím docílit obyčejného failoveru, ale chybí tomu spoustu věcí na řešení různých případných split brain.
Na co jsem např. narazil bylo, že občaš došlo ke split brainu v případě zálohování VM. Jakmile se nachvilku freezla, tak druhý node vyhodnotil, že primár je neaktivní a šel nahoru, nasadil si VIP apod. Pak se ale VM odfreezla a hádej co, najednou byly v síti dvě stejné VIP a Keepalived to neřešil a vesele komunikoval s druhým keepalived dál. Na to existovala další obezlička v nějaké patchnuté verzi (= vynucování kontroly kdo je master), ale i tak k tomu někdy za jiných okolosnotí může dojít.
A to se bavíme o řešení na stejné L2 vrstvě, představa, že v tom bude routing, je trochu děsivější.
Dále se neřeší další scénáře, takže proto je lepší pro core věci použít peacemaker, corosync apod.
Zdar Max

[Heron]

Já to také nepovažuji za finální řešení. Proto jsme myšlenku glusterfs velmi rychle opustili. Testoval jsem jen, jestli to funguje by default, kritické stavy už jsem netestoval, to už bylo dávno odpískáno a šlo se jinou cestou (sas storage s několika řadiči pro několik esx). Osobně se mi sice nelíbila cenovka, jsem přesvědčen, že za tyhle peníze bychom to dali i na čistě oss řešení (ale třeba jinak, se stejnou redundancí), ale je pravdou, že za tyhle peníze jsme dostali plně funkční řešení.

Osobně bych to celé navrhl jinak, bez vmware, bez centrálního pole, redundanci řešit na úrovni jednotlivých vm. Levnější hw ve větším počtu. Takto jsme byli omezeni licencí, co se týče počtu nodů a jejich cpu apod. Na OSS si tam nastrkáš tolik levných serverů kolik chceš. Na 10 menších nodech se ti redundance řeší lépe, než na omezeném počtu esx serverů. A tak dále. Ale vedení si vybralo jinou cestu, bylo ochotno zaplatit cenu za jedno Ferrari (no, tolik to zase nestálo) a dostalo funkční řešení.

Stále mi v hlavě leží tohle. Aktuálně je k disposici RPi4 8GB RAM za velmi slušnou cenu. V domácích kompech mám celkem 15 disků. Říkám si, že, kdybych postupně koupil 6 nebo do budoucna 12 RPi a ke každému z nich připojil jeden datový disk, tak získám: 48ARM CPU cores, 96GB RAM, 12xHDD storage a obrovskou redundanci. Nahodit na to 12 worker kontejnerů pro zpracování mých dat (videa stejně konvertuju na desktopu), další kontejnery pro další věci, dns, mx, monitoring. Asi největší problém by byl storage, jistě, lze mít 12 samba shares, ale chtělo by to nějaký clusterový fs, který řeší redundanci. Tohle by mi doma fakt stačilo, dá se to pořizovat postupně z kapesného, cena je příznivá, a postupně by to nahradilo ty dva desktopové servery. Navíc redundance jako prase, když mi teď chcípne FreeBSD stroj s 10 jaily, tak by to byl problém. Kdyby mi chcípla jedna RPi deska z osmi, tak se ty kontejnery pustí na ostatních. Klidně i automaticky. Škoda, že to rpi nemá sata.

Řešili jste tohle někdo? Používáte něco podobného? Nasadit to poloautomaticky s pomocí ansible je trivka. Teď jsem si během pár desítek minut naspawnoval 16x vmko v hyperv a už to fičí. Připravit další node na novém rpi nebude trvat ani hodinku, nastavit v něm kontejnery už je potom běžná rutina. Všechno to vypadá až moc dobře, nějaké problémy tam jistě budou. Tak sem s nimi. (Ano, výkon rozsekanej na x strojů, výkon jednoho jádra nic moc, paměťi je naráz k disposici pouze málo apod. tohle je všechno jasné. Ale praktické nevýhody? Borec - estét - řeší nevzhledné napájení, tak k tomu má POE switch. Tohle je mi jedno. Fyzické provedení, klidně vedle sebe na polici. Je to malé. Kdyby bylo potřeba, může to ofukovat skupinka pomalu běžících větráků. Co dál?)

[NadaMac]

ahoj Heron tiez som sa bavila s glusterfs pred 3 rokmi... v lete kupila firma zelezo na CEPH cluster (3 nodes) a teraz nam bezi PROXMOX cluster (5 nodes) s HA, pricom som urobila viac HA groups zvlast pre CT a zvlast pre VM v zavislosti od: server resources, server connectivity, server room/ups, service master/slave...

Proxmox aj Ceph je open a vela ludi ich pouziva aj doma na vlastnom zeleze, ktore postupne vylepsuju 8-) Vela zdaru.

[Heron]

Jo, tohle vím. Proxmox mám v prioritním todo, už to řeší kolega v kanclu. Dle infa od jiného člověka je CEPH z roku 2016 a dneska úplně jiný. (Tomu se říká stabilita projektu.) Dáme tomu další šanci, ale aktuálně pro nemá prio. Kdybyste někdo měli stroj na klonování lidí, tak se nechám naklonovat 10. Děkuji.

[trekker.dk]

Heron a Ceph: když je to špatné, tak je to špatné, protože je to špatné. Když to vylepší, tak je to špatné, protože je to nestabilní.

[Heron]

Prostě mám trochu jiné nároky na vedení takto důležitého projektu. Od storage požaduji stabilitu. Očekávám, že se projekt v čase bude asymptoticky přibližovat k nějakému ideálu a nebude dělat zásadní změny. Takže ano, když je to špatně, je to špatně. Když dělají neustálé změny, tak to značí, že vlastně neví, jakou cestou se vydat. A to je špatně. I toto je kritérium pro nasazení libovolného programu na servery v mé správě. A budu to psát po každé velké změně. Stejně jako vy budete reagovat.

[trekker.dk]

To je možné, ale výsledek je takový, že různým projektům měříte různým metrem a tvrdíte, že (podle vámi zvoleného kritéria tak, aby to vyšlo) je ten metr stejný. A konkrétně pro tenhle projekt, který jste nebyl schopen sám nainstalovat, ten metr měří hůř než pro jiné.

[Heron]

Já jsem se o to nikdy ani nepokusil takže toto vaše tvrzení je chybné. Právě proto, že vůbec nesplňoval nároky. Co se postupně potvrzovalo, když to nasadil kolega a povedlo se nám to na počkání shodit. Co víc k tomu psát: náročně na nasazení a nefunkční (stav 2016). Jistě můžete psát, že vám to funguje a že vy to nainstalovat umíte. Ok, je možné, že kolega udělal někde chybu, ale to pouze přidává k náročnosti instalace a konfigurace. Fakt nejsem zvyklý trávit hodiny laděním něčeho. Server do produkce dostanu klidně do 1h, dle rychlosti HW a bootu. Instalace OS, nastavení uživatelů, nastavení disků, instalace postgresu, monitoring. Každý krok je jednoduchý a trvá 5minut max. Server pro 2TB databázi. Triviální věc.

Jestli instalace čehokoliv vyžaduje více než 10 kroků a trvá hodiny, tak je to prostě špatně. Je to ukázka špatně vedeného projektu. A na tom na základě zkušeností prostě trvám. Nový webserver pro libovolný cms mám hotový za 20minut včetně https od LE a prvního rozepsaného článku. Ani ansible playbook se mi pro to psát a testovat nechce. Tak je to snadné. Ale klidně si dál pište podobné komentáře.

[trekker.dk]

Moje tvrzení se zakládá na všem tvrzení. Něco o tom, že jste nepochopil dokumentaci nebo tak - a ano, pak jste to hodil na hlavu kolegovi. Pravda, tu část o tom, jakým způsobem se vám to povedlo na počkání shodit, už si nepamatuju... Zbytek je přesně to, co jsem psal - jako obvykle jste si zvolil metr tak, aby vám vyšel výsledek, který chcete.

[Heron]

Ne, já jsem to nikdy neměl na starosti a nikomu jsem to na hlavu nehodil, ale výkaz práce zde skutečně zveřejnovat nebudu (ani jej nemám) a navíc by to bylo nepodstatné a zcela zbytečné.

Shodit se nám to povedlo tak, že jsme na tom pustili pgbench nad několika postgresql databázemi. Ve skutečnosti méně, než běžně běželo v produkci. Stačilo pár desítek minut běhu pgbench na několika virtuálkách (malá čísla, něco jako 10 nebo 8). Celkový datový tok a iops na takto postavený storage byl menší, než běžný provoz na produkci a přitom HW to mělo tehdy velmi nadstandardní. Hromada SAS 16x SAS per node, 4 Intel DC SSD. Spousta RAM (128GB). Tři node. Takto luxusní hw pro storage jsme v produkci tehdy skutečně neměli. Tedy 8VM dokázalo shodit storage o 12xSSD, 48SAS HDD (10 nebo 15krpm, to už nevím).

Zkoušeli jsme to na blokové vrstvě RBD a do vmware přes iscsi - preferované řešení. Zkoušeli jsme přímo do těch virtuálek připojovat cephfs a datový adresář pro postgresql dát do něj - tohle bylo doporučované, mít spoustu cephfs klientů pro data. Tohle bylo ještě horší, tady stačilo pár minut. Zkoušeli jsme někam připojit cepfs, exportovat je jako NFS a toto NFS připojit do vmware a virtuálky na něm.

Virtuálky se po pár (desítkách) minut zasekly. Výkon storage klesal až k nule a potom to vmware vzdal a prohlásil storage za nedostupný. Při připojení cephfs přímo do virtuálek se to chovalo stejně jako nfs mount při výpadku sítě. Všechny procesy v uninterruptible sleep. Ano, po dalších x hodinách se to probralo. Takže se můžete klidně vozit po výrazu "shodit". cephfs vyloženě padal s nějakým errorem, který už nemám. Ano, RBD nespadlo, jen mělo několik hodin výkon 0IOPS. Takže to vyloženě nespadlo, ale provozovat produkci na 0IOPS nelze.

Toto rozhodně nebyl stav, na kterém by bylo možné cokoliv produkčně provozovat. Když 48+12 disků dokáže shodit 8 virtuálek, je to za mě nepoužitelné.

Vlastně nevím, co myslíte tím dvojím metrem a je mi to už jedno. Věnovat tomu dalších x desítek hodin nemělo žádný smysl. Prostě to nefungovalo. Nezvládalo to provoz, který jsme měli běžně na produkci. Mělo to k dispozici nadstandardní HW - 10GbE síť, 4x cache SSD, 16xdatové disky. Oddělená síť pro synchronizaci ceph. Každý stroj 4x10GbE port. Víc jsme tehdy neměli a už tohle byl nadstandard, který jsme v produkci neměli.

Takže tak.

[trekker.dk]

Ne, já jsem to nikdy neměl na starosti a nikomu jsem to na hlavu nehodil

Tvrdíte teď, tvrdil jste něco jiného.

Zkoušeli jsme to na blokové vrstvě RBD

Aha, takže vaše tvrzení "shodili jsme Ceph [cluster]" ve skutečnosti znamená shodili jsme konkrétního Ceph klienta. Že mě to nepřekvapuje.

Prostě to nefungovalo.

Budiž, tohle beru. Rozhodli jste se použít klienta, který nefungoval, takže nefungovalo řešení, které jste se pokoušeli nasadit. Vy to ovšem od té doby používáte jako zkratku k "Ceph je špatný" a vymýšlíte si metriky tak, aby vám toto tvrzení podkládaly.

[Heron]

A můžu se zeptat, kterého dalšího klienta jsme měli použít, když: RBD byl nepoužitelný, CephFS byl nepoužitelný, S3 object storage jsme použít pro vmka nemohli? Předem děkuji za odpověď. Ano, někde uvnitř možná nějaký ceph proces běžel, ale to je celkem na nic mít storage, kam se nelze připojit. Ale možná jsem to jen špatně pochopil a celý CEPH je jen o uctívání ideálního storage, kam je v podstatě zneuctěním vůbec chtít připojit nějaké klienty a vyžadovat diskový výkon.

(Jen mě zajímá, kam až ve své absurdnosti zajdete. Nic víc.)

[trekker.dk]

RBD byl nepoužitelný

RBD byl nepoužitelný pro vás. To je zase taková vaše lež-nelež (v angličtině je na to pěkný výraz lie by omission), kdy vynecháte nějaký malý detail, aby to vypadalo, že něco, co se vám nelíbí, je horší, než tomu ve skutečnosti je.

[Heron]

Přesně tak. Nám výkon 0IOPS po několika desítkách minut nic moc testovacího provozu nevyhovoval, naši zákazníci od serveru očekávali o něco větší diskový výkon než nula, a dívat se na vmware, jak storage označuje za nedostupný také pro naše nasazení nebylo úplně vhodné, takže jsme toto řešení nenasadili do provozu. A vůbec si netroufám zpochybňovat, že tento výkon někomu jinému může pro jeho služby stačit. Ale my jsme měli o něco málo větší nároky.

A nemám problém napsat, že se mi to nelíbí. Aktuální nároky na storage mám 30kIOPS a minimálně 500MB/s. Prostě klasické tuctové ssd. Prostým matematickým porovnáním 0 a 30k jsem zjistil, že 0 je méně než 30k a proto jsem si zvolil aktuálně 30k. Ale opět, nikomu to nevnucuju, je to jen moje kritérium.

Stejně tak jsme v tom roce 2016 zjistili, že výkon nula za cenovku přesahující milion Kč a spousty hodin práce je přece jen o něco méně, než jaký výkon nabízí běžně dostupné komerční diskové pole, které levou zadní zvládalo 1GB/s a tehdy více než dostatečných ~10k IOPS ze tří ESX serverů současně. Jinými slovy, nezůstaly nám žádné důvody dál testovat CEPH a měli jsme to vyřešeno k naší spokojenosti. Ale opět, nenechte se nikdo ovlivnit tímto pohledem na svět a používejte si co chcete.

[trekker.dk]

A vůbec si netroufám zpochybňovat, že tento výkon někomu jinému může pro jeho služby stačit.

To odpovídá na otázku, kam zajdete ve své absurdnosti.

Zásadní ovšem je, že přestože vy jste kvůli svému způsobu nasazení nedokázali Ceph použít, neznamená to, že Ceph je špatný, ani to, že jste ho dokázali na počkání shodit, jak tady trvale lžete.

[j]

Copa ti rozbil za babovicku?

Osobne naprosto souhlasim s tim, ze pokud neco nefunguje po 10 minutach a nekdo mi bude vykladat, ze kdyz venuju 30 clovekohodin konfiguraci, tak to MOZNA fungovat bude, tak ho kopnu mezi pulky - a to hned. Za cenu tech 30 hodin mam totiz jiny, a funkcni reseni.

Pricemz sem si 100% jisty, ze hodiny straveny konfiguraci cehokoli, vygeneruji nasledne nejmin tisicinasobek hodin stravenych udrzbou.

BTW: Predvadecku citrixu sem s kolegackem sejmul behem prvnich 5 minut a bylo po predvadecce, protoze se jim to zprovoznit uz nepovedlo. Vazne myslis ze takovou jebku nekdy nekam nasadim? Ani kdyby mi za to chteli platit. Je mi uplne uprdele co a proc jim chciplo.

---

Dete s tim guuglem dopice!

[Heron]

Čéče my fakt musíme někdy zajít na pivko. Jinak to, sto pro souhlas. Příkladů z praxe už je tady a v jiných diskusích uvedeno dost.

Pricemz sem si 100% jisty, ze hodiny straveny konfiguraci cehokoli, vygeneruji nasledne nejmin tisicinasobek hodin stravenych udrzbou.

Ano. Moje zkušenost z praxe je taková, že když nějaká věc jde jen s obtížemi nainstalovat (nebo prostě jen návod na instalalaci obsahuje 200kroků), tak její provoz bude už jenom horší. Fakt nevím, odkud pramení bezbřehý optimismus mnoha kolegů, že stačí projít instalací a všechno bude fajn. Kdy naposledy se tohle stalo?

Predvadecku citrixu sem s kolegackem sejmul behem prvnich 5 minut a bylo po predvadecce

Mno... raději nic. Já už rozbil takových "nezničitelných" věcí...

[trekker.dk]

Tak nějak jsem čekal, že si s broukem pytlíkem, co všude byl, všechno viděl a jeho příspěvky mají přinejmenším 50% šanci, že se v nich tvrdí naprostý blábol (tato diskuze není výjimkou - příspěvek hned o kousek vedle), zanotujete. Svůj (lhář) k svému.

[Heron]

To tak prostě v životě chodí. Pokud tady pan j uvádí více méně stejné zkušenosti, jaké mám sám, nebo si alespoň na základě jiných zkušeností dovedu živě představit, že přesně takto se to mohlo odehrát, tak je mi zkrátka mnohem sympatičtější než někdo, kdo soustavě překrucuje všechno co řeknu, hledá ve všem naprosto nepodstatné a vůbec nic neřešící detaily a na těch se snaží vozit. Ano, jsou věci na kterých se s j neshodneme, ale stejně by mě zajímala jeho zkušenost (například z oblasti databází). A dovedu si živě představit, že pracoval s nějakým absurdním produktem, ve kterém to bylo přesně tak, jak píše. A na základě toho on zase nevěří mě když píšu o jiném produktu, kde ty šílenosti nejsou. Ale jeho komentáře, na rozdíl od komentářů některých jiných diskutujících, obsahují nějakou zkušenost a nějakou myšlenku.

[trekker.dk]

krátka mnohem sympatičtější než někdo, kdo soustavě překrucuje všechno co řeknu, hledá ve všem naprosto nepodstatné a vůbec nic neřešící detaily a na těch se snaží vozit

Nikdo takový se tady sice neobjevil, ale chápu, že když se omezíte jen na tato vybraná kritéria - jak je vaším zvykem - tak vám takový závěr skutečně může vyjít.

[Max]

S dovolením se do této diskuse vložím a prohlásím, že již bylo řečeno vše a je zbytečné tu nadále hrát pinčes o ničem .
Zdar Max

[j]

"Stále mi v hlavě leží..."

Myslim ze tohle je hodne papirovej predpoklad. Ona totiz jakakoli redundance predpoklada nejakou elementarni stabilitu nodu, a to je neco, co malina nema. Takze IMO timhle jen vyrobis neco extremne nestabilniho. Naopak, cim vic takovych nodu mit budes, tim to bude horsi.

Jinak sme pro zakose resili variantne vsan vs pole. A vyhralo to po vsech strankach pole. Bylo to jednak levnejsi, a i spolehlivejsi. Ono sice hezky znelo, ze si jako das "levny" disky do serveru, a usetris za "drahy" disky do pole, jenze kdyz mas to pole, tak chciplej srv = zadnej problem. Kdyz mas vsan, tak chciplej (nebo i z duvodu udrzby odstavenej) srv = ztrata redundance.

Co si pak pamatuju, tak ruzny ubermultinode fs se tu uz parkrat v diskusich resily, a krome jinych veci, prakticky nezasadnejsi a velmi obtizne resitelnej problem je v tom, kdyz se ti to rozpadne na vic (2+) segmentu, a kazdej si tim padem o sobe mysli, ze je tim co prezil.

---

Dete s tim guuglem dopice!

[trekker.dk]

Každopádně někteří místní by ti řekli, že řešit failover pomocí RSTP je out of date, protože dnes existují řešení, které splní jak failover, tak mají oproti RSTP možnost využívat všechny trasy (LACP, IRF apod.) U routerů se dost často pro ten základ používá VRRP.

Akorát se tím u těch switchů dostáváte asi tak na desetinásobek ceny, protože je potřebujete stackovat, což switche za ~30k umí, ale až switche za ~200k to umí dobře. (A to se bavím jen o gbit switchích)

[j]

Jenze tohle ma spoustu nevyhod a funguje to jen jako velmi lowend reseni. Protoze potrebujes ty porty na tech vecech co k tomu pripojujes, a zaroven si tim zlikvidujes moznost znasobit konektivitu - jednoduse proto, ze ten druhej kabel bude proste odpojenej.

A jako bonus, pri tom vypadku switche ve skutecnosti dojde k vypadku konektivity, se kterou by si sice kazdy zarizeni melo poradit, ale realne casto neporadi.

Zcela pak pomijis veci, kery sou napajeny pres PoE. Ukaz mi aspon jedno takovy zarizeni, ktery ma 2 porty a zaroven se pres oba da napajet.

Dalsi vec na ktery si typicky nabijes hubu je ta, ze on ti nechcipne ten switch, ale ta UPSka, a ty proste nemas kam to prepojit, protoze nemas konektory nebo vykon (protoze se to prece dimenzuje na ty veci, co do toho jsou zapojeny "normalne").

Takze pokud tohle vsechno chces eliminovat, tak proste potrebujes dvojzdrojovy swiste. A neni to nic co by bylo nejak nedostupny, jak sem uz psal, jen si musis vybrat spravnou radu. Idealne pak s necim cemu cisco rika vpc. Protoze tim zaroven docilis reseni vypadku elektriny + vypadek switche a zaroven pouzivas oba ty kabely protoze se to z pohledu toho zarizeni chova jako bond/team/ethchannel/...

Primarne je to samo dycinky vo tom, jestli provozovatel realne chce(predevsim zaplatit) reseni takovych situaci. Na spouste mistech to pochopitelne nedava smysl resit, protoze naklady budou adekvatni nebo vyssi potencialni skode.

Jinak takovej muzealni kousek pro priklad 4948 ... 48port gbit a ma to dva zdroje(a podle varianty to uz muze mit i 10G uplink). Pokud chces neco vic aktualniho a vic khull tak trebas Nexus 31108. 10G + 100G uplink, dva zdroje + vpc.

---

Dete s tim guuglem dopice!

[Heron]

PoE v racku neřeším. Jaká zařízení potřebují poe? O čem se bavíme, o racku v dc, nebo o racku ve firmě, kde jsou na tom telefony? V DC tohle přece neřešíš.

A jako bonus, pri tom vypadku switche ve skutecnosti dojde k vypadku konektivity, se kterou by si sice kazdy zarizeni melo poradit, ale realne casto neporadi.

Je potřeba to vyzkoušet. Při přechodu na 10GbE někdy v tom roce 2016 jsme na to měli síťaře, vše nastaveno, vše odzkoušeno, vše funguje, můžeš si vesele vytahovat kablíky ze switchů a ono to stále komunikuje. Jak je to přesně nastaveno - ty protokoly, o kterých píše Max, já nevím. Ale síťaři to umí. A by bylo fajn, kdyby o tom někdo napsal článek jen pro info, co všechno je možné nastavit a kde jsou limity.

ale ta UPSka

Přesně tak, viz komentář výše.

[Max]

Jinak asi máš pravdu, že to asi nebude mít jednoduché řešení, protože to, co vyletí, závisí na hodně faktorech. Naposledy jsem např. řešil jeřáb, kterýmu bouchnul přívod, prošlo to k vlastní trafačce a přes ní to vyhodilo i přívod od PRE. To by nebylo nic divného, ale tato krásná akce vyhodila jističe i v dalších budovách, které byly na úplně jiné, oddělené větvi.
Zdar Max

[j]

To je normalka, vzniklo ti tam vpodstate neco podobnyho EMP. Mas tam proudovej a napetovej naraz, a ten ti proste probubla i na kabely, ktery nejsou vzajemne propojeny. Co se myslis stane, kdyz ti do baraku praskne blesk. Klidne muzes mit svody v naprostym cajku, ale vse co je elektronicky proste chcipne. Tohle je totez, jen v mensim.

Hele, co mi skleroza slouzi, tak APCcko dodavalo k nekterym UPSkam (a obavam se ze prave k tem velkym kravam stojicim samostatne) nejaky rozsirujici moduly, ktery prave umely i samostatne odpojovat jednotlivy skupiny a komunikovalo to primo s tou UPSkou, takze ta o tom vedela. Prakticky se to chovalo tak, ze placnu UPSka jako takova mela 5 skupin, a ten modul pridal dalsich 5. Tech modulu mohlo byt N. Ale pocitam ze takova sranda bude stat randal, a pokud nemas 10+ racku zeleza, tak nema smysl o tom premejslet.

---

Dete s tim guuglem dopice!

[j]

Hele Maxi, videl sem PDUcka ktery sou rozdeleny na 2-3 skupiny a je na tom jistic, ale to ti stejne nijak nezaruci, ze ta UPSka nebude rychlejsi. To dava smysl v pripade, ze ta UPSka je schopna dodat radove vic = rozhodne ne UPSka v racku, to sou takovy ty kravy ktery stojej samostatne.

A i kdyby sis to sam vyrobil, coz principielne neni problem, budes na tom uplne stejne. A viz fous niz, pokud to mas udelany tak, ze ty stroje maji dva zdroje, tak ti to, ze padne jedna vetev nijak nevadi. Coz je defakto taky jediny spravny reseni.

Ostatne pouziti jednozdrojovyho cehokoli === na bezvypadkovym provozu nesejde.

---

Dete s tim guuglem dopice!

[Max]

Problém je, že se mi toto stalo třeba u Cisco SG550X-47MP. To už je celkem slušný kousek. Má sice podporu Cisco RPS2300, které se dá použít jako záloha v případě výpadku primární trasy, ale obávám se, aby to "uvnitř" nebylo jen hloupě propojený a zkrat na zdroji by mi tím pádem sundal obě větve a redundance by zase byla tatam.
Znám totiž řešení, které se tváří, že mají dva zdroje, ale ve skutečnosti nemají. A takové zařízení pak mohou sundat obě větve a udělat ještě více škody :-/.
Pokud je tedy jediným řešením koukat na drahé kousky a mít ověřeno, že mají skutečně dva oddělené zdroje, tak ok, ale čekal bych, že bude existovat něco, co to minimalizuje.
Na PDU s několika oddělenými skupinami jsem už narazil, ale lepší ochrana jednotlivých zásuvek než skupiny :).
Zdar Max

[Max]

Tak jsem koukal na ten Cisco RPS2300 a toto by asi bylo řešením v případě tohoto konkrétního switche, jelikož je to konektor přímo na desku a vyžaduje externí zdroj.
Ale je to jen jedno z mnoha zařízení, ostatní takové věci nemají.
Zdar Max

[R]

Neviem, odkial si zobral ten nezmysel s prepojenim dvoch zdrojov vnutri. Tym by si skratoval dve napajacie vetvy, ktore nemusia byt vo faze (jedna moze bezat zo siete a druha z UPS alebo generatora) a to by bol ohnostroj.

Velke zdroje mozu mat viac vstupov (napr. velke Cisco zdroje 4200W) pre pripad, ze zdroj ma vacsi odber ako 16A (limit jednej zasuvky). V pripade Cisca su dokonca aj tieto vstupy oddelene.

[Max]

Zřejmě jsem se jen špatně vyjádřil. Já to myslel tak, že tam nejsou fyzicky dva zdroje, ale reálně jen jeden, který nemusí být odolný vůči všem poškozením jako dva fyzicky oddělené zdroje.
Zdar Max

[j]

Realne sem teda neco takovyho jeste nevidel ... sem obcas i propojopval 2 bezny PC zdroje, kdyz to udelas spravne, tak to normalne funguje a o zatizeni se podelej. Pokud bys mel odber vetsi, nez jeden z tech zdroju unese, tak by mela predevsim zafungovat ochrana toho zdroje === ten zdroj proste nesmi ani do zkratu dodat vic (zkratovanej PC zdroj bud nezapnes, nebo se po nejaky dobe vypne).

Bezne jde takovej zdroj i za chodu vytahnout celej ven, a pripadne vymenit. Tudiz samo musi kazdej jeden zvladnout 100% zatez toho HW. A maji to rek bych celkem bezne servery od nejakych rekneme 50k nahoru. U swistu je to v zavislosti na rade, ale u klientskyho je ti vetsinou dost jedno, ze umre pri nejakym vypadku, protoze pak stejne vetsinou umrou i ty klienti, takze se prevazne delaj jednozdrojovy.

S tim co chces ve svym dotazu je proste problem v tom, ze ty v 99% pripadu nemas dost informaci o parametrech tech prvku tak, abys moh prohlasit, ze to bude fungovat.

Staci se mrknou na beznej rozvod elektriny, a pocitam ze i spousta lidi tu ti potvrdi, ze se bezne deje to, ze ti vypadne jistic v byte/baraku, ale zaroven s nim vypadne i jistic na pripojce. Samo, je to spatne, ale tak to proste je. Jde o to, ze ten jistic ma nejakou charakteristiku a ne vzdycky vypinas zkrat. To je naopak spis vyjimka. Takze z hlediska tech jisticu jde spis o vypnuti nadproudu(vykonovy jisteni), a tam zalezi na tom, jak rychle a na jak velkej proud to reaguje.

Mno a presne v tomhle okamziku budes hrat loterii s UPSkou, jestli to driv odpoji ona nebo ten jistic.

Kazdopadne v okamziku kdy po me nekdo chce odolnost proti tomu ze trebas chcipne napajeci vetev nebo UPSka, tak jednoznacne rovnou kupuju veskerej HW s dualnim napajenim. Uz sem totiz i videl takovy "jakoze" bastly, kdy k tomu internimu zdroji dodavali dalsi, externi. A i kdyz to urcite bude fungovat, tak z hlediska organizace toho bordelu v racku tohle je pro me naprosty no-go.

BTW: Pro svoje privatni poteseni sem si samo i takovy veci dobastloval, trebas i k tem jakoze cisco vecem (linksys) pridas ten druhej zdroj (oba budou externi) proste tak, ze si ho nekde sezenes, a primastis tam druhej konektor. Fukncne je to stejny, protoze spojujes uvnitr uz stenosmer. Takze si to pak z kazdyho zdroje veme +- 1/2 amper. Ale tohle bych samo nikomu do firmy nedal ani ve snu. Doma to tak mam proto, ze se proste swist z druhyho zdroje zapne hned jak nabehne elektrina, zatimco primar je na upsce, ktera se jeste dobiji.

---

Dete s tim guuglem dopice!

[R]

Minule sa im "podarila" zaujimava vec: pripojil som zdroj k UPS, ale nejaky kokot na nom prepol prepinac na 110V a nevsimol som si to. Ochranne varistory v zdroji sa skratovali, poistka prdla a vyletel istic. UPSka sa normalne prepla na bateriu a bezala. Takze PC, co som mal tiez na tej UPS, normalne zostalo bezat.

[V]

Zběžně jsem to tu prolétl a překvapuje mě, že nikdo nenapsal, že se tohle normálně řeší pomocí ATS

Škatule do racku, má 2 vstupy a mezi nima přepíná. Takhle řešíme věci, co mají jeden zdroj a nemusím bastlit žádné rychlé jističe a podobné...

[Max]

A jak to prosím řeší zmíněný problém?
Zdar Max

[V]

Tak, že když ti nějaké zařízení (např. nějaký server se dvěma zdrojema nebo nějaká levná škatule na monitoring) vyrazí jednu UPS tak se to okamžitě přepíná na druhý vstup bez toho, aby byl downtime?

Samozřejmě se na to připojuje jenom to kritické.

A taky to pochopitelně neřeší problém, když ti bouchne zdroj v tom jednom prvku, který má jeden zdroj a je kritický - ale to nevyřeší ani svěcená voda protože špatně je už ten návrh...

[Max]

Ty jsi ale zjevně nepochopil otázku. Navíc toto řešení tu bylo již zmíněno.
Toto ti nijak nepomůže na to, na co jsem se ptal. Tj. když máš zdroj ve zkratu, tak ti to prostě sundá všechno společného včetně ostatních prvků, co na té větvi jsou. A tím, že si nainstaluješ takový přepínač, tak nejen, že ti to sejme jednu větvi za UPS, ale vadný zdroj ti sejme obě větvě, protože to ten vadný zdroj po schození první větvě přepojí na druhou, kterou pak shodí také. Tzn. že tímto řešením se vytvoří ještě větší problém.
Zdar Max

[V]

Je to klidně možné, že jsem nepochopil. Podle mého chápání otázka zněla, jak zabránit výpadku kritického zařízení na společném přívodu elektřiny v situaci, kdy nějaké zařízení tenhle přívod přetíží. Z kontextu dotazu jsem to chápal tak, že to zařízení co způsobí problém je jiné než to kritické - jinak by totiž ten dotaz nedával smysl. ATS tuto situaci přesně řeší.

Pokud ti shoří to kritické zařízení, tak máš prostě smůlu. Navíc obě větve to neshodí neb ta ATS sama má pojistku - to by musela shořet i ta ATS.

Nicméně ať vymyslíš cokoli, tak vždycky jenom posouváš tu hranici selhání někam jinam ale vždy tam bude a downtime budeš mít tak jako tak a v podstatě se jenom snažíš vymyslet rovnák na vohejbák, kterým bys špatný návrh/implementaci alespoň trochu podepřel místo toho, abys to udělal robustně od základu (nemyslím to útočně, je to bez ohledu na důvody - ať už to jsou čas nebo prachy nebo cokoli dalšího).

Otázka pak spíš je, že pokud daná věc nemá přiděleno dost prostředků na robustní řešení tak zjevně nebude v očích zodpovědné osoby natolik důležitá aby nějaký downtime jednou za pár let vadil. V takovém případě pak řešíš v podstatě zbytečnou činnost, protože stávající stav je z definice dostačující

[Max]

Tak to jsi pochopil špatně a nevím, jak jinak to lépe vysvětlit, než tak, jak jsem to popsal.
Řeší se prostě situace, kdy v jednom PDU/ATS je zapojeno více zařízení a jedno z nich je ve zkratu. ATS pak není řešením, naopak celou situaci ještě zhorší.
Zdar Max