Мар. 072007
 

Трудно се започва от определена точка. Може би корена е дълбоко забит в MPP (massive parallel processing) идеите, които по-късно се прекръщават на clustering. Там силните на деня (в края на 70-те години) са DEC, IBM и Cray. Може би първият успешен клъстер е ARCnet, създаден от DataPiont през 1977. Той е бил подходящ за изследователски цели, помагал е на университети, но не се е наложил като търговки продукт.

Първи комерсиален успех постигат DEC с техния VAX cluster в началото на 80-те. Той е работил върху VAX/VMS и освен изчислителна мощ е разпределял и файлове, и периферни устройства. За съжаление управлението на разпределените заключвания при него (DLM, Distributed Lock Management) е оптимизирано за работа с относително малко на брой ресурси (примерно файлове и устройства), а не за хиляди и десетки хиляди буфери в Buffer cache на СУБД. Той „не скалира добре” (виж предната статия).

За това Oracle, когато решават да създадат СУБД, която да може да работи в този клъстерен режим, си създават собствен DLM. Това става по времето на версия 6 на Oracle database. В началото това е предизвикало недоумение – да си създаваш свой DLM вместо да използваш този на DEC? В крайна сметка DEC са основоположници на цялата клъстерна идея, техния продукт е доста успешен!

Но се ражда Oracle 6.35 (преименуван на 6.2 за да се отпразнува светлия празник) с неговия Oracle Parallel Server (OPS) – първата клъстерна БД. Оказва се, че DLM на Oracle работи много добре с VAX клъстерите на Digital. Всъщност работи толкова добре, че самите DEC го вземат и го добавят като част от техния клъстерен стек. Така когато излиза Oracle 7, той отново работи с вградения DLM на Digital.

В началото на 90-те много варианти на UNIX въвеждат възможност за клъстеризация. Те се базират основно на DLM от Oracle. Дори Microsoft правят стъпки в тази посока (но техния DLM не е взет от Oracle – не, той е от Digital 😉 ). В това време Oracle 7 използва клъстерния стек на ОС и така доставя тази услуга под различните UNIX платформи. За съжаление инсталацията и настройката на OPS е доста сложна, защото се синхронизират множество слоеве от различни доставчици.

Когато на бял свят излиза Oracle 8, в него има общ lock manager, който е явна индикация, че Oracle подготвят собствен клъстерен стек. Lock manager-а е в кода на СУБД като има малка част OSD (Operating-system dependent) код. По този начин може да се гарантира еднакво поведение на всякакви платформи. По-късно този код влиза като част от ядрото на Oracle и е познат като IDLM (Integrated Distributed Lock Manager).

Oracle 9i RAC използва този собствен IDLM при всички платформи, но разчита на външен clusterware (освен под Linux и Windows). Във версия 10g вече целият стек се доставя от Oracle (въпреки че пак е възможно да се интегрира с външен Cluster manager).

За да се клъстеризира една БД с помощта на OPS са необходими следните „нива”:

– Cluster manager – наблюдава възлите на клъстера, грижи се за синхронизацията между тях, предприема необходимите стъпки ако някой възел „отпадне”. Той е в OSD слоя и (обикновено) се доставя от доставчика на ОС. Пример за такъв софтуер са Sun Cluster (за Solaris), Service Guard (за HP UX), HACMP (за IBM AIX)

– Distributed Lock Manager – отговаря за заключванията, чрез които се постига консистентност и интегритет на БД. Грижи се до всеки общ ресурс да има достъп само от един възел в един момент. Не отговаря за транзакционните (потребителски) заключвания

– Cluster interconnect

– Shared Disk array

 Posted by at 9:48

Sorry, the comment form is closed at this time.