Master Yavor from Tryavna

Снощи правих контролиран експеримент за производство на „Кавърма по воденичарски“ в домашни условия. Нямам кулинарните умения на Панев, но имам самочувствието, че поне нещо толкова елементарно мога да сглобя.

Набавих необходимите продукти от „Пикадили” – най-хубавото свинско месо, което успях да позная; зеленчуци, свежи подправки… Какво казва Буги Барабата: „Важното е хляба да е бял, пък хайвера може и да е черен”. И понеже нямах много време, се заех веднага с приготвянето.

Както обикновено, оказа се, че готвенето е елементарно. Слагаш 5-6 неща на камарка и започваш да кълцаш. Не мога да разбера, обаче, защо се престарах толкова с подправките – особено с черния пипер. И не че не ставаше за ядене – напротив! Само че го нямаше лежерния вкус, който търсех… Добре че дойде Тя и ми показа как се спасява такава манджа. Сложихме малко сметана и експеримента, колкото и странен, се оказа успешен.

После си похапнахме сладко сладко. Не на свещи, но с бяло вино. Вечерта отново стана приказна.

Ако някой не е чул или разбрал, съвсем скоро – на 11 юли – Oracle ще пуснат новата версия на най-железния database management софтуер: Oracle 11g. Според всички източници (сред които и страхотната презентация на Пламен Зюмбюлев на последния семинар на БГПО), очакват ни наистина интересни времена.

Няма търпение да „разцъкам“ новата играчка. Вероятно в първите дни download-а от oracle.com ще е бавничък, но хубавите неща стават бавно…

Oracle счупиха поредния си рекорд. Този път става дума за цена на производителност (price/performance) и резултата е 0.74 USD/tpmC (100 926 транзакции в минута срещу $78 049). Става дума за една доста позната (за мен) платформа: HP ProLiant ML350. Желязото е с 1 4-ядрен процесор, 24 GB RAM, малко над 100 диска(признавам, тава е малко нереално за production) и Oracle Standart Edition One (подробности – тук).

Идва ред на всички, които плачат че Oracle Database e „хубав, ама маного скъп…“ да прегледат мотивите си. От общата цена на системата (включваща 3 години поддръжка на железата, ОС и БД) , цената за Oracle софтуер и поддръжка е под 10%: $6 992.

Да ни е честит новия рекорд

п.с. Малко по-надолу Micro$oft имат аналогична конфигурация (ML350, 1 CPU/4 cores, 20 GB RAM, 100 HDD, $77 122 обща цена). И постигат 82 774 tpmC / 0.94 USD/tpmC, или с 20% по-зле. Знам аз с какво да работя… 😉

Днес изслушах една лекция за “Oracle RAC Internals” на Барб Лъндхилд. Направи ми впечатление, че когато обяснява за изгонване на нод от клъстера (node eviction) спомена, че използват STONITH алгоритъм.

Ще започна от малко по-рано. Както, предполагам, всички читатели на моя блог знаят, RAC е технология на Oracle, при която много сървъри работят като един. За целта те имат едновременен и равноправен достъп до общ дисков масив, на който се помещава самата БД. За да не стават сакатлъци с данните, всички заявки за писане (че даже и за четене) на общия дисков масив са синхронизирани между нодовете. Тази синхронизация става през мрежовата връзка, която е изградена специално за това (private interconnect). През нея, освен всичко друго, постоянно летят и един съобщения между всички участници в къстера: „Жив ли си” – „Жива съм. А ти жив ли си?” – „И аз съм жив. А ти жив ли си?”…

Така… Когато се случи да отпадне мрежовата връзка към възел Х, той започва да не чува останалите (важи и обратното – останалите не чуват Х). Тогава освен „Жив ли си” започват да се губят и другите мрежови пакети, които служат за синхронизация на писането върху общия дисков масив: „Аз смятам да пиша сега блокчето с данни по номер ХХХХХХ” или „Трябва ми блокчето YYYYYY, някой променял ли го е (да ми го изпрати) или да го чета от диска?”. Когато се загубят тези съобщения за синхронизация, има реална опасност да се повреди базата – примерно ако 2 нода запишат различни версии на един блок. Това се нарича split-brain (шизофрения?).

За да се избегне split-brain ситуацията, когато прекъсне връзката между нодовете, веднага всичките се събират на специално направения за такива цели Voting disk (препоръчва се да не е само 1, а 3, за по-сигурно) и гласуват кой е жив и кой кого вижда. Формира се мнозинство от най-голямата група от нодове, които се виждат по между си (Барб Лъндхилд спомена, че ако са равни по брой участници групите, печели тази група, в която нодовете имат по-малки номерца). Тази група оцелява, другите биват изгонени (node eviction). Точно това „изгонване“ се случвало по STONITH алгоритъма.

И, в крайна сметка, какъв е този STONITH алгоритъм? Проверих в wikipedia…Оказа се, че STONITH не е име на някои умен професор, който го е измислил. Това е просто абревиатура от Shoot The Other Node In The Head, или Застреляй Другия Сървър В Главата (ЗДСВГ). Е нека някой ме убеди, че клъстернте решения се измислят само от скучновати вратовръзковци (има и едно доста вселяшко обяснение на STONITH тук)