Изпечатай

[Ipolit]

Здравейте,
решихме да си направим High Availabilty система, ама до сега никога не съм се занимавал с такива неща и затова търся помощ.
Системата на първо време ще е от 4 съвръра и споделен SAN -iSCSI. Всичко е чудесно, обаче идея си нямам как да я направим, че да е оптимално откъм цена и да позволява евтино разширение.
След като правих една гора калкулации, започнах да отхвърлям варианта с оптични връзки към SAN-а, защото Fibre Channel картите са над 2000 лв. и освен това повечето SAN-ове имат 4 FC порта, и без някакъв разширител ще си спрем възможностите за добавяне на съвъри.
Затова започнах да гледам 10GB SFP карти, като цената им е доста по-ниска от тази на FC картите. Тук обаче се появяват 2 въпроса:
1. Дали такъв тип връзка е достатъчна за работа с отдалечения storage - вероятно да, защото поне хипотетично скоростта е по-висока от тази на оптичните влакна, но са по-бавни по отношение на I/O. Би следвало обаче да няма проблем, при положение, че доста хора реализират подобни схеми и през гигабитови карти.
2. Тъй като SAN-овете имат 2 SFP 10Gbs, а аз мисля да включа първоначално 4 сървъра, ще са необходими и 10 гигабитови суичове. И понеже говорим за highavailability, очевидно че трябва да имам поне 2 суича. Тук пак става въпрос за цени. Дали ме устройва да ползвам неуправлявани 8 портови Realtek, които са на доста приемливи цени или трябва да се търси някакъв друг вариант.
Може би е добре да кажа, че системата ще е пълна виртуализация на около 20 сървъра върху Xen Server.
И още неясноти - SFP картите като обикновени мрежови карти ли се настройват и двата им порта да имат един и същи адрес, та ако ми се събори единия суич, системата да продължи да работи през другия - същото важи и за SAN-а.
Въобще все неща, които не съм ползвал, а първоначалната инвестиция е доста голяма и не мога да си експериментирам.
Предварително благодаря за всякакви съвети.
Поздрави

[backinblack]

Тази тема и мен много ме вълнува, че смятам съвсем скоро време да събирам втори сървър за виртуализация.
От моя скромен опит в тази материя, без предишен в професионалното сървърно поприще, някак си, тези комбинации със сториджи и скъпи връзки нещо не ми харесват. Установих, че за да вървят добре виртуалките на сървъра и требе да има много бръз многодисков райд масив.
Струва ми се, че райд 5 е по-добре за виртуалки заради по-високата скорост на запис която се постига, но пък тя зависи от рама и процесора на контролера май и се отива на по-скъп контролер, но сякаш всеки сървър със собствен си масив е по-изгодното и ценово ефективно решение, при положение, че има много голямо разнообразие от маломощни до свръх мощни сървъри и лесно могат да се мигрират виртуалки от един сървър на друг.

[Ipolit]

Ами ако искаш да постигнеш свръх надеждност, трябва да го направиш по някакъв такъв начин.High availability имаш ако нямаш нищо дето като се счупи спира системата. Като са ти на САН виртуалните машини, ако се счупи един от сървърите, другите автоматично му поемат виртуалните машини. Много е яко, аз си го симулирам от известно време с iSCSI от FreeNAS. Ама не знам как се прави с истински компоненти. Иначе сме се виртуализирали от 3 години, ама ако умре физически сървър отнема много време да го възстановиш - импорта на бакъпнати имиджи е примерно 2-3 часа.

[BRADATA]

https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial
ето ви четиво за размисъл

[Ipolit]

Благодаря за линка. Като цяло при мен ситуацията е по-различна и това, което ме тревожи е как се настройват портовете за връзка със САН-а. ДРБД няма да ползвам на първо време и въпросът е точно както обяснява човекът във Вашия линк, какво се случва при паднал суич. И най- ме интересува дали двупортовите карти са с различна настройка за всеки порт или автоматично при паднал суич се ползва другия порт. Ще го разгледам утре по-подробно, мисля че има много полезни неща.
А иначе самите сървъри дори може да са бездискови, може да има PXE boot от САН-а на операционната система на хипервайзъра. Но аз мисля да си сложа на сървърите нещо, на което да си инсталирам XEN-а.

[BRADATA]

Принципно х-портовите карти имат отделен мак за всеки порт. В конкретния пример се използват три двупортови карти с три суича - всеки с определена роля. Картите са резервирани една с друга по определена схема. Най-важния елемент в системата се явява управляемия захранващ източник - той рестартира неотговарящите устройства. Прочети подробно статията и ще ти стане ясно каква е схемата.

[gat3way]

Нямам вземане даване с такива неща от години, та нещата сега сигурно са различни, но преди да си сменя попрището, имах доста вземане-даване с HA клъстери.

Това:

След като правих една гора калкулации, започнах да отхвърлям варианта с оптични връзки към SAN-а, защото Fibre Channel картите са над 2000 лв. и освен това повечето SAN-ове имат 4 FC порта, и без някакъв разширител ще си спрем възможностите за добавяне на съвъри.

Предполагам имаш предвид storage сървърите. Идеята не е да правиш 4 FC loop-а между сториджа и 4-те сървъра, това е малко...екзотична организация на нещата. Обикновено тези неща се решават със FC суичове, но пък те са скъпички. Иначе чувал съм че 10gbps етернета убивал FC в последно време.

1. Дали такъв тип връзка е достатъчна за работа с отдалечения storage - вероятно да, защото поне хипотетично скоростта е по-висока от тази на оптичните влакна, но са по-бавни по отношение на I/O. Би следвало обаче да няма проблем, при положение, че доста хора реализират подобни схеми и през гигабитови карти.

Мисля, че сравнително рядко ще ти се налага да удряш ограниченията на bandwidth-а така или иначе, така че това няма огромно значение. По мое време масово се ползваше 4gbps FC, сега май е масово 8gbps. Разликата не е чак толкова огромна предполагам (прецизни сметки обаче не съм правил, при етернет на физическия слой хартисват по-малко битове за error correction, отделно трябва да се направят сметките колко хартисва за протоколните хедъри, предполагам при варианта с iscsi, нещата позагрубяват, fcoe може би е далеч по-добре).

Тъй като SAN-овете имат 2 SFP 10Gbs, а аз мисля да включа първоначално 4 сървъра, ще са необходими и 10 гигабитови суичове. И понеже говорим за highavailability, очевидно че трябва да имам поне 2 суича. Тук пак става въпрос за цени. Дали ме устройва да ползвам неуправлявани 8 портови Realtek, които са на доста приемливи цени или трябва да се търси някакъв друг вариант.

Не, дай малко повече пари за умни суичове. Защото ще можеш да си правиш от "хубавия" ethernet bonding (802.3ad). Цицковските суичове имаха някаква наклонност да го позволяват да става между два отделни суича и така се постига оптимума - хем link aggregation, хем high-availability наклонности.

И още неясноти - SFP картите като обикновени мрежови карти ли се настройват и двата им порта да имат един и същи адрес, та ако ми се събори единия суич, системата да продължи да работи през другия - същото важи и за SAN-а.

Предполагам за MAC адрес иде реч - това зависи от bonding режима. При 802.3ad доколкото помня имаха един и същ MAC адрес (откъдето е важно суича да знае да говори протокола), но може и да греша. При FC, нещата са малко по-различни, там не може (или поне нямам спомени да може) да се агрегират интерфейси. Имаше няколко варианта за multipathing-а, но в общият случай най-често се виждат като различни пътища и като отпадне единия път, другия става активен, а device mapper-а се грижи това да става безболезнено (обаче никак не е безболезнено, о неееее, много често сме дебъгвали reset-и в loop-а и изпопадали пътища, бяха грозни работи).

Мисля, че софтуерната страна на нещата е къде по-комплексна в крайна сметка обаче.

[neter]

Не, дай малко повече пари за умни суичове. Защото ще можеш да си правиш от "хубавия" ethernet bonding (802.3ad)

Е, ако само заради bonding-а ще ги взема тези умни суичове, няма смисъл - софтуерният bonding в Linux е достатъчно надежден и поддържа няколко режима на load balancing и backup. Но ако бюджетът му позволява, да си вземе умни, пък все ще намери за какво да ги оползотвори за допълнителни цели в занятието

[gat3way]

Да и всичките режими си имат кусури - или само агрегират или имат само един активен интерфейс, или когато тръгнат да правят двете, става забавно (в единия режим всеки интерфейс има отделен мак адрес и таблица с кой хост през кой интерфейс говориш и когато връзката през някой интерфейс се осере, съответно до експирясването на ARP entry-то, няма връзка, в другия режим пък знаеш единствено дали твоя линк е ОК, ако примерно trunk-а на суича загуби свързаност поради някаква причина, щастливо продължаваш да бълваш трафик през този интерфейс). Не знам де, в зависимост от случая, може и да те урежда, но ако държиш на uptime-а на услугата, според мен поне за това ще дадеш пари.

П.П. сигурно изглежда глезене, обаче след като си решил да ползваш shared storage и клъстерни файлови системи, трябва да знаеш че забавата става пълна в момента в който дори за кратко нямаш свързаност. Ще започне fence-ване на нодове, верижни самоубийства и не е особено забавно

[BRADATA]

Да и всичките режими си имат кусури - или само агрегират или имат само един активен интерфейс, или когато тръгнат да правят двете, става забавно (в единия режим всеки интерфейс има отделен мак адрес и таблица с кой хост през кой интерфейс говориш и когато връзката през някой интерфейс се осере, съответно до експирясването на ARP entry-то, няма връзка, в другия режим пък знаеш единствено дали твоя линк е ОК, ако примерно trunk-а на суича загуби свързаност поради някаква причина, щастливо продължаваш да бълваш трафик през този интерфейс). Не знам де, в зависимост от случая, може и да те урежда, но ако държиш на uptime-а на услугата, според мен поне за това ще дадеш пари.

П.П. сигурно изглежда глезене, обаче след като си решил да ползваш shared storage и клъстерни файлови системи, трябва да знаеш че забавата става пълна в момента в който дори за кратко нямаш свързаност. Ще започне fence-ване на нодове, верижни самоубийства и не е особено забавно

Що да не е забавно Забавно е Особено като се опиташ да възстановиш всичко и на главата ти са се юрнали (баси яката българска дума) един болюк клиенти /недоволни/

[Ipolit]

Едва ли е толкова трагично, все пак хората ползват такива неща и им викат high availability. А ако е, просто ще си карам с ФриНАС-а и ще спестя педесе хиляди.

[gat3way]

Много често хората си надценяват нуждите наистина. Иначе съвсем сериозно, нещата не са толкова красиви. Дебъгването на проблеми свързани с клъстерни файлови системи като GFS или OCFS2 наистина е кошмарно занимание. Конкретната причина, поради която реших да си сменя професията донякъде свързана с това, ако трябва да съм честен. В един хубав ден, в който единият нод от един DB клъстер, критичен за фирмата се беше отсвирил, докато оправяхме проблема, по грешка рестартирах работещият нод, изолиран от клъстера (щото в момента в който го вкарвахме, нещо не се разбираха за кворума и почваха да се ритат взаимно). Стана голяма тарапана и нямахме услуга в продължение на известно време. Точно това беше момента в който реших че нямам повече нерви и желание да се занимавам с тези работи. Така че внимавайте - може да ви откаже от професията

[BRADATA]

Едва ли е толкова трагично, все пак хората ползват такива неща и им викат high availability. А ако е, просто ще си карам с ФриНАС-а и ще спестя педесе хиляди.

Помисли си по въпроса много сериозно. Защото ако ти трябва high availability само за един сървис - има много по елегантни решения (репликация за СУБД например) които са в пъти по евтини и прости. High availability cluster е нещото което ще се наложи да направиш ако си решил да пускаш виртуализация на много машини, което пък е по добре да го направиш с някакъв тип blade решение.

[Ipolit]

Лошото е, че ми трябва наистина. Има няколко свръхкритични услуги и няколко пъти по толкова критични. Ще си троша главата. А иначе и аз искамда сменям службата - това си е работа за млади надъхани мераклии. 10 години ми стигат

[n00b]

Много често хората си надценяват нуждите наистина.

Другия проблем е че когато покажеш и цифрите се почва - "дай да измислим нещо по-така". Е то няма HA, хем по-така.