ASM: Fast Mirror Resync
Въведение:
Преди известно време Oracle обявиха пускането на пазара на Exadata Storage server. Това нещо представлява един HP DL180 G5 сървър наблъскан с 12 твърди диска. На него работи Oracle Linux 5.1 и малко допълнителен софтуер, който дава възможност на всеки Oracle Database 11.1.0.7 или по-нов да вижда тези 12 диска като локални през infiniband връзка. На практика това е нещо като shared storage, на който, обаче дисковете му се виждат като дискове, без никакви опити за RAID-ване. Всъщност има възможност от всеки физически диск да се направят няколко griddisks, като се прецизира физическото разпределение върху плочите.
Задачата:
Имам конфигурация с няколко Exadata cells и една RAC DB, чиито файлове са разположени върху тях. Искам да проверя какво ще се случи ако отпадне цял cell – дали ASM ще успее да поддържа работата на БД без абсолютно никакво прекъсване и колко време ще синхронизира дисковете като му ги върна. Дисковите групи са настроени с normal redundancy, т.е. всички данни са налични на 2 места (mirror).
Част 1:
Спирам без предупреждения един cell. В alert log-а на БД се появяват грозни съобщения:
Mon May 25 14:32:19 2009
Errors in file /ora11g/diag/rdbms/XXXX/XXXX1/trace/XXXX1_ckpt_31632.trc:
ORA-27603: Cell storage I/O error, I/O failed on disk o/10.0.1.153/DATA_CD_3_sagecell03 at offset 16826368 for data length 16384
WARNING: IO Failed. subsys:OSS dg:1, diskname:o/10.0.1.153/DATA_CD_3_sagecell03 disk:0x13.0xea55c0a4 au:4
iop:0x2af98b9dcaa0 bufp:0x2af98b757e00 offset(bytes):16826368 iosz:16384 operation:2(Write) synchronous:0
result: 4 osderr:0xc osderr1:0x0 pid:31632
OSS Subsystem error:12 (OSS_ERRCODE_NETWORKERR)
...
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 1 on disk 19 allocation unit 4
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
NOTE: initiating MARK startup
Starting background process MARK
Mon May 25 14:32:20 2009
MARK started with pid=42, OS id=21872
NOTE: MARK has subscribed
Такива неща има за всичките дискове от този cell. В alertlog-а на ASM се появяват още грозни съобщения:
Mon May 25 14:32:19 2009
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
WARNING: kfk failed to open a disk[o/10.0.1.153/DATA_CD_2_sagecell03]
И тук такива съобщения има за всичките дискове от този cell.
Въпреки това БД продължава да си работи с пълна сила.
Част 2:
След около час и половина, в които БД работи без прекъсване, включих спреният cell. Както може да се очаква, ASM не може да се сети сам за тях – за него те са offline и той не ги търси. Закачих се с SQLPLUS към един от ASM instance-ите в клъстера:
SQL> select MOUNT_STATUS, NAME from v$asm_disk;
MOUNT_S NAME
------- ------------------------------
...
ONLINE DATA_CD_7_SAGECELL04
OFFLINE DATA_CD_2_SAGECELL03
OFFLINE DATA_CD_5_SAGECELL03
OFFLINE DATA_CD_12_SAGECELL03
OFFLINE DATA_CD_8_SAGECELL03
OFFLINE DATA_CD_1_SAGECELL03
OFFLINE DATA_CD_10_SAGECELL03
OFFLINE DATA_CD_6_SAGECELL03
OFFLINE DATA_CD_3_SAGECELL03
OFFLINE DATA_CD_9_SAGECELL03
OFFLINE DATA_CD_4_SAGECELL03
OFFLINE DATA_CD_11_SAGECELL03
OFFLINE DATA_CD_7_SAGECELL03
ONLINE DATA_CD_9_SAGECELL02
...
За да събудя възстановяването на данните от огледалните копия върху вече наличните дискове пуснах следната команда:
SQL> alter diskgroup DATA online disk DATA_CD_7_SAGECELL03,DATA_CD_11_SAGECELL03,DATA_CD_4_SAGECELL03,DATA_CD_9_SAGECELL03,DATA_CD_3_SAGECELL03,DATA_CD_6_SAGEGECELL03,DATA_CD_1_SAGECELL03,DATA_CD_8_SAGECELL03,DATA_CD_12_SAGECELL03,DATA_CD_5_SAGECELL03,DATA_CD_2_SAGECELL03;
Diskgroup altered.
SQL> select * from v$asm_operation;
GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE
------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- --------------------------------------------
1 ONLIN RUN 1 0 0 0 0 0
SQL> /
no rows selected
Както виждате, операцията е толкова бърза, че не можах да засека за колко време стана. Всъщност това е относително очакван резултат.
Защо става така:
Първо, при спирането на cell-а симулираме просто отпадане на диск. Е, всъщност на 12 диска. Това може да е породено от софтуерна или хардуерна грешка. Една от основните функции на ASM като high availability решение за дискове е да се справя в такава ситуация. И той наистина се справя – мърмори си в alertlog-а, но продължава да работи.
По-хубавото е бързото възстановяване на данните. Причина за това е новата в Oracle 11g функция Fast Mirror Resync. Когато един или няколко диска отпаднат без предупреждение, ASM започва да си записва кои extent-и са променени на огледалното копие. Така когато диска се върне, вместо да се rebuild-ва цялото огледало (12 диска по 450 GB са 5.4 терабайта!), се копират само промените. Това спестява много време и много IO. Естествено, това е полезно само ако се върне същият диск – примерно ако е имало проблемен кабел, повреден контролер, рестарт на cell и т.н.
Заключение:
И при отпадане на диск, и при връщането му, ASM работи много добре и точно според „рекламите“.
Още по въпроса
Тук не използвах параметрите ASM_POWER_LIMIT и новия за 11g DISK_REPAIR_TIME. Не знам дали и те работят както се очаква, но предвид видяното, нямам причини да се съмнявам.
42 Responses to “ASM: Fast Mirror Resync”
Sorry, the comment form is closed at this time.
Относно темата за ASM и прословутата Exadata. За тази страхотна система от няколко HP DL180 G5 машини, които най-вероятно са пълни със SATA диск-ве или SAS в най-добрия случай плащаш някаква баснословна цифра на Oracle, да не говорим за лицензи и така нататък…Извода какъв е? Купуваш си яко over-priced желязо със „страхотния“ ASM, който ASM е също толкова нескопосан както и самия Oracle RAC барбар със CRS-a вътре. Яко vendor lock-in. Страхотна сделка правиш…няма що… 🙂 .
Ти пробвал ли си го, че да знаеш каква е сделката? Щото да ти кажа честно, за сега няма нещо, което да сме пробвали на него и да не работи поне 3 пъти по-бързо (минимум!, при OLTP натоварване).
Като мислиш, че това е яко vendor lock-in, що не пробаш други DWH appliances – примерно Teradata, на която един прост SQL не върви, или пък Netezza. С Exadata поне имаш относително стандартни компоненти.
Но ако твоята система си върви добре и на жълт сървър и MySQL, да, прав си, не ти трябва Exadata..
Кой, казва че Teradata е по-добра?? Там shit-a е още по голям. 3 пъти по-бързо, защото някой не си е оптимизирал базата и не си е мръднал пръста за да прегледа какво прави Oracle и какви select-и се блъскат вътре ама това е друга тема…просто се опитват да оптимизират малоумните select-и на програмистите (страшен начин за решаване на проблема, типично за Oracle) . Факта е, че Oracle се опитват да прилапат колкото се може по-голям пазар и за това гледат да изблъскат всички, което няма да стане. Конкретен пример Oracle CRS (заместник на клъстерни решения от други vendor-и, complete FAIL), ASM-а е някакъв опит да се заместят storage вендор-те, което само по себе си е complete fail, открили са RAID-a…браво това е похвално 20 или 30 години след всички други…
„Моята“ системата, не работи на жълто желязо….и ползва Oracle RAC + CRS и като изключим малоумието на CRS-a за сега работи…
Exadata си е чисът маркетингов трик. А и не съм убеден,ч е на Mtel му ‘трябва’ Exadata, както казваш ти. АМ хайде радвайте се и се пъчете най-вече, че си имате Exadata.
@Hades: Значи, казваш, Oracle CRS е заместник на клъстерни решения от други vendor-и и е complete FAIL? Интересно, знаеш ли защо и кога е възникнал CRS? Нека ти разкажа малко история. С версия 6 на Oracle Database са пуснали Oracle Parallel Server, първата комерсиална клъстерна база в света. По това време единствените читави клъстерни решения са били на Digitall, за VAX/XMS върху nCube машини. Обаче Oracle са си създали собствен lock manager, защото тоя на Digital по идея е бил проектиран да се справя с относително малък брой ресурси (примерно с устройствата), а не с хиляди и десетки хиляди блокове памет. Това, тогава, е изглеждало пълна глупост – в крайна сметка Digital де факто са излмислили клъстерите (комерсиално, поне). Обаче се оказва, че Oracle-ския distributed lock manager е толкова добър, че Digital са си го вкарали в техния клъстерен стек. И с излизането на версия 7, Oracle отново използват Digital-ския DLM.
После всички юникси започват да предлагат клъстерни услуги, и всички вземат точно Oracle-ския DLM. За това Oracle 7 (и 8, че и 9) използва „vendor clusterware“ – щото интересната част са си я написали те, и им харесва.
Когато и Microsoft решават да се правят, че тяхната ОС може да предлага клъстериране, те не взимат този на Oralce. Взимат DLM-а от Digital 🙂
Така че Oracle имат дългогодишна традиция в клъстерирането, и, честно казано, все още не съм виждал друг софтуерен клъстер, който да се оправя с (вече) милиони ресурси Active-Active – както прави RAC в Global Resource Directory. Е, вярно, има си бъгове – кой софтуер няма, еле пък толкова сложен. Но в момента само IBM могат да предложат нещо аналогично, а там цифтоманията е още по-драстична.
Друго: ASM-а е някакъв опит да се заместят storage вендор-те, което само по себе си е complete fail, открили са RAID-a…браво. Какво лошо има да предлагаш конкурентно решение? Освен това ASM не е само RAID, той е и logical volume manager, и файлова система, сам по себе си. Не знам за теб, ама аз виждам някои предимства в това колкото се може по-голяма част от стека да ми се съпортва от една фирма. Няма прехвърляне на топката.
Oracle се опитват да прилапат колкото се може по-голям пазар – Ми коя фирма не го прави?
@Tedi: Аз не искам да обсъждам какви нужди има MTel и как ги задоволява. В моя блог аз говоря за технологията, която харесвам (или не)
Значи,
CRS не е RAC, като за начало. Не знам дали го знаеш този малък факт. CRS-a управлява ресурси, instance на базата ( кога се вдига спира и etc. ) също така управлява IP aliase ( който се мести при нужда ) и на последно място, но не по-малко важно: той взима решения за това какво става в случай на fail на някой от node-те. Ти говориш за RAC, което е Real Application Cluster. Аз говорех за CRS-а, НЕ за RAC-a. Сама по себе си идеята на RAC-a е интересна, защото предлага доста предимства.
ASM: Лошо няма да предлагаш конкурентно решение стига да е адекватно, а не да е някое недоносче, което умишлено не се слага в доста фирми с по-голям Oracle Admin капацитет от този, в която ти работиш.
Не съм казал, че това да се набутваш на всякъде само и само да си разшириш корпоративното портфолио понеже продажбите са ти паднали е някаква революционно добра идея, особенно когато се хвърляш в области, които са доста по далече от това, което до сега си работил. Ако го правиш както трябва, super!! Но от моя скромен опит до сега, мога да кажа че много малко фирми се справят ( за справка на некадърниците виж HP, Microsoft, Oracle със тоя CRS-а ). Ако забрлязваш аз нямам против Oracle, тяхната база е най-добра за Enterprise с големи инсталации. Казвам го понеже си мислиш, че просто troll-я :), срещу Oracle като цяло, което не е вярно.
Вярваш или не, аз знам каква е разликата между CRS и RAC. Просто исках да изтъкна факта, че oracle са едни от основоположниците на клъстерирането и знаят как се прави. А за това дали CRS е по-зле от, примерно, HP ServiceGuard или RedHat Cluster, да не говорим за MSCS… Много може да се спори. Честно казано, до сега само IBM HACMP не съм хващал в издънка, и то може да е защото нямам забележим опит с него.
За това къде се използва ASM и къде – не: всеки си има право на избор. Някой го харестват и използват, други – не. На мен не ми е правил много пръчки (само малко 😉 ), за това съм му фен. Според мен пък се използва на доста места и е доста удобен. Вярно, че е относително нов продукт и има това-онова за излгаждане, но се развива доста. Помисли дали не бъркаш като го приемаш като просто средство за замяна на RAID контролера. Все пак той прави много повече неща.
Значи един от основните недостатъци и проблеми на CRS-а е това, че си вързан с ръцете по конфигурацията му, по простата причина че за да го съпортват по-лесно. Oracle искат да имат колкото се може по-проста конфигурация с минимални интервенции от страна на потребителя с цел предсказуемост. А това по себе си е едно голямо NO-NO за всеки сериозен проект, защото в крайна сметка ситуацията в различните фирми изисква различни решения на проблемите, с които се сблъскват. Аз имам скромен опит с HACMP-то и мога да ти кажа, че там може да се правят чудеса от храброст стига да искаш и да знаеш как. Това е така защото е предвиден да работи не само с Oracle ами със всевъзможни vendor-и, и това изисква гъвкавост на решението. CRS-а е една малка пръчка, която е като черна затворена кутия и уверението на Oracle „relax everything is OK, we have it covered“ изобщо не ме топли ни най-малко. Защото утре като се овапца нещо аз ще си троша тиквата с техните недомислици и меко казано малоумни решения на някои проблеми. На презентации и разни други fancy изпълнения, в които всичко се рисува в розови цветове съм се нагледал доста. Това е marketing crap, който един професионалист изобщо не го вълнува.
Можеш ли да споделиш нещо по-конкретно, което ти липсва или смяташ, че не е добре/логично/правилно измислено/направено? Ако си присъствал на последния BGOUG знаеш от лекцията на Пламен, че скоро той ще представя пред Oracle Developers искания какво ние, потребителите, искаме от бъдещите версии. И честно казано, те наистина се вслушват.
Така че ако имаш някакви разионални и конкретни предложения, моля те да ги споделиш – тук или по мейла, или направо да ги обсъдим.
Ако не, оставаш си само с думите „CRS-a е FAIL, life sux, точка„.
Subject: CSS Timeout Computation in Oracle Clusterware
Doc ID: 294430.1
Това е от metalink-a, не знам дали си го виждал този док. Сега като го прочитам пак виждам, че са правили промени разни, но като цяло мисля че поведение на CRS-a си е останало същото. Обърни внимание на таблицата с поведението на CRS-a, при загуба на някой от интерфейсите по които му върви HB, и как Oracle кардинално са решили проблема. Само олигофрен би halt-нал машина понеже му паднал единя от интерфейсите по който върви HB, а най-малоумното е че това НЕ може да се промени, защото не е supported и е hardcoded в самия CRS. И за клиента остава само да се моли на бога, че няма нещо да примигне в трафика на HB канали, защото машината ще се отсвири, без предупреждение.
[…] понеделник писах за приятната възможност на ASM за Fast Mirror Resync. Тогава забравих да спомена за един параметър (също […]
1. Не разбирам проблема, моля обясни. Не ти харесва начина, по който CRS реагира за да се избегне split brain, или не си съгласен, че при отпадане на HB има split brain?
2. За да не падат интерфейси си има препоръки за adapter teaming на ниво ОС.
3. Ти вероятно знаеш, че през interconnect не върви само hartbeat, а и cache fusion (когато имаш RAC). Без него така или иначе нода не може да продължи.
При загуба на единия интерфейс за HB, при наличие на N+1 за какъв split brain говориш бе мен..?? Като падне interconnect по който върви Cache Fusion, кво пречи да почне да се ползва public, макар и с изкуствено намален performence?? За това, че интерфейсите трябва да са резервирани не ми говори, знам го много добре… Това което не ми харесва е, че Oracle са решили че отпадането на кой да е от интерфейсите за HB трябва да се оправя чрез reboot на host-а. Предполагам това е някакво ментално изкривяване от дългата работа с Windows на тия дето са го писали това недоразумение CRS…
Оправянето на проблема с split brain, при другите вендори е чрез reboot, защото software-а който управлява клъстер-а НЕ знае как да си говори с application-а и да му каже, че има проблем и да спре да се опитва да пише по дисковете/FS-те, друг е въпроса че IO-то може да се отреже и това решава проблема с data corruption-a, и създава проблема data integrity. Да не говорим, че дори и това му поведение може да се промени…
Като за човек, който се изказва толкова компетентно по въпросите на клъстерните технологии, знаеш учудващо малко по тази тема…
Лекциите на Зюмикс-а, няма нужда да ги слушам, след като видях че е избран за Oracle Admin на 2008-ма…дори няма да го коментирам….
Такааа… Не знам защо толкова се палиш и все те избива на обиди, явно си си такъв по природа. Както и да е.
Ако разполагаш с N+1 интерфейса за interconnect, логично е да ги team-неш. Подозирам, че те дразни това, че ако ги обявиш на Oracle за N+1 самостоятелни private интерфейса, отпадането дори на единия събаря всичко. Това наистина не е велико решение, но предвид, че може (и се препоръчва) да си ги team-неш на ниво OS, не е такава драма. Друг е проблема ако искаш да имаш разни видове interconnect – примерно ethernet за HB и infiniband за cache fusion. Но това вече става супер custom решение.
Това, че при отпадане на нод се прави reboot на хоста също го разбирам по-различно от теб. Идеята не е да се копират бъглявините на Windows. Идеята е просто нещастния самотeн нод да бъде спрян, веднага, тотално. Т.е. не е важен рестарта, а стопа. Но от друга страна, след акто е спрян, нищо не пречи да се пусне отново – ако успее да се закачи към клъстера, добре дошло.
Въпросът като падне private interconnect, да почне да се ползва public връзката, вече сме го повдигнали пред Oracle. Т.е. тук предложението ти е добро, но закъсняло 🙂
Не обиждам без причина, просто се дразня страшно много когато хора дават мнения по въпроси по които хал хабер си нямат…както и да е.
HB interconnect-те, ТРЯБВА да минават през различни среди!!! ТОВА Е ЗАДЪЛЖИТЕЛНО, иначе нищо не правиш.
Защо ако не е тайна трябва да се спира host-а?!?!! Защо не се спре само базата?? „shutdown abort“??? Тая команда барем я знаят в Oracle…? Спирането на някъв смотан Linux blade или Windows, може да не е голяма работа и да е в реда на нещата, но спирането на машина с 256G RAM, 64 CPU-ta и кво ли още не, не е някакво нормално събитие на което всички трябва да си правят снимки и да се отваря шампанско.
Относно прехвърлянето на трафика от private към public, това е трябвало да бъдя ако не във весия 1.0 на продукта то не по-късно от 1.01, защото не трябва да си rocket scientist за да ти дойде на ума…
Оф, преди един час знаех „учудващо малко по тази тема“, сега вече „хал хабер си нямам“. Я поне ти, като си такова светило в областа, в която аз имам толкова да уча, се представи, стига си **** от удобната си анонимност. Че поне да знам от кого да се уча, ако имам достатъчно мозък. Напомняш ми за Mladen Gogala, който едно време се подвизаваше из oracle-l, но той едва ли знае български.
Моя скромен опит показва, че понякога дори и shutdown abort се успива. В случая, с който имаш split brain (който трябва да е много рядък, екстремен случай), е по-добре да играеш на сигурно.
Това което исках да кажа е, че трябва човек да се поблъска и да се порови малко повече в същината на проблема, а не да цитира разни slide-ве на разни хора, като папагал…приеми го като конструктивна критика…макар и груба.
Ако базата се успива на shutdown abort, тогава направо kill -9 на dbw процесите?? За CRS-а отпадането на 1 от N+1 HB интерфейса е split brain, което само по себе си е тотално алогично и обезсмисля наличието на N+1 HB-a на първо място. Добре, че като отпадне единия от общо 2 или 3 канали за комуникация на host-a, не са го направили да се свалят предпазителите на захранващото табло на целия BOX…че не ми се мисли…
Не можеш да се откажеш от анонимността, явно. Приятно ти е да ***** скрит там, в дълбоката сянка, без да се налага да отговаряш за думите си… Е, това е впрос на избор.
ОК, като изтрепеш dbw процеса, какво следва? Какво става с другите клъстерни услуги на нода, примерно с VIP-а? Или ще трепеш и него? А с всички други, включително custom, услуги, които могат да се търкалят от CRS?
И още, ще събориш DBW, ама после много зор ще вдигнеш instance-а автоматично. Трябва да се почисти паметта, да се поизтрепе ако има някой успал се процес… Трудно ще стане без човешка намеса. Така че нода е down и си остава down.
За разлика от рестарта. Там, ако проблема наистина е бил временен, машината си се вдига и се join-ва обратно. Ако може, естествено. Да, ако става дума за желязо с 256G RAM и 64 CPU-та, статртирането става бавно. Но всъщност от такива машини се очкава да имат проблеми адски рядко. Освен това, потребителите не остават без услуга по време на рестарта, дори и в този екстремен случай. Нали за това има други нодове.
Какво значение има кой съм, приеми че съм някой който е сърбал попарата на CRS-a достатъчно…
Какво значение има какво става с VIP-a?!? Дори и да си виси, зад него няма кой да отговори…клиента отива на другата машина и тва е…?
Ти ако си мислиш, че машината прави shutdown през ОС-а…и всичко се затваря и се sync-ват дискове и т.н. си в страхотна заблуда…Предпочитам базата да ми е down, но host-a да е up. Вместо да гледам тъпо терминала и да се чудя WTF?!?!?!
Големите BOX-ве има много рядко проблеми, така е. Но в случая проблем, който е тривиален и не критичен се решава от някакъв недомислен application, по абсолютно недопустим начин. И става така, че от малък проблема се превръща в ОГРОМЕН, защото някой дето го е пусал това няма акъл за 5 пари и не мисли за друго решение ами спира host-a, понеже така му е най-лесно и не му пука за това какви са последствията от тези действия.
А да, и да join паднал node, в клъстера автоматично при вдигането на host-а??? Това ли искаш да ми кажеш или аз нещо съм недочел…?
Естествено, че не се прави graceful спиране през ОС. Прави се възможно най-бързия и груб restart, точно за да не се sync-ват дискове и т.н. Split brain ситуацията не е тривиална и е доста критична. Всеки един запис на shared storage-а от такъв нод може да направи ужасни поразии. Като човек, дълбоко запознат с теорията и практиката на клъстерите, би трябвало да знаеш това.
А за това че ****ш анонимно… по тоя начин мнението ти доста олеква в очите на случайният читател. За това се надявах да застанеш с името, опита и репутацията си зад своите думи.
В очите на случайния читател, аз вадя конкретни доводи/аргументи и примери, които ти не може да обориш с конкретни аргументи, а заставаш с „името“ си като аргумент. Аз нямам кой знае какъв опит и репутация, рядко ми се налага да правя шарени презентации и да разтягам локуми, просто си върша работата тихо и кротко :).
Според мен ти не вадиш толкова аргументи и факти, колкото нападки и подхвърляния – това било FAIL, онова било измеслено от олигофрен, а аз „хал хабер си нямам“ и повтарям „като папагал“ чужди презентации. Но дали това са аргументи и факти, или обиди и заяждания, естествено, е въпорос на субективна преценка. Между другото кратката историческа справка, която ти сведох, не съм я чел само от статията на Кари (с която, явно, си запознат), а я проверих и в още 2 книги, в които се разказва за историята на Oracle и RAC. Какво да направя, обичам да се ровя в историята на нещата, с които се занимавам. Мисля, че по този начин осъзнавам по-добре кое как и защо е направено.
„Какво значение има какво става с VIP-a?!? Дори и да си виси, зад него няма кой да отговори…клиента отива на другата машина и тва е…?“ тук, явно, не си наясно с идеята за съшествуването на този VIP. А идеята е точно когато един нод отиде в тиквите, друг да поеме адреса само и единствено за да отговаря с resеt на връзките и да не се чака timeout преди клиента да тръгне да се закача към някой друг.
Бих искал да те попитак нещо друго. Присъствал ли си на моя презентация на БГПО? Ако изключим най-първата (на сбирката в Трявна), която бях изнуден да направя без да се чувствам достатъчно уверен, коя друга смяташ че е шарения и разтягане на локуми?
@Yavor Факт е, че Хадес си те завря в миша дупка. Признай си и не спори като не си подготвен.
Аз съм запознат с HP ServiceGuard-а и смея да твърдя, че както и HACMP-то и този софтуер е пъти по-добър от ORACLE CRS. Оракъл май наистина се опитват да изместят вендорите и да продават едни кутии ORACLE както каза HADES, но това е малко вероятно да стане. Откраднаха RedHat линукса, купиха SUN за железата и са готови 🙂
Направо да купят и EMC и да го махат това безполезно говно ASM, на никой сериозен администратор не му трябва администрация на дисковете от базата данни.
[…] постинга ми за ASM: Fast Mirror Resync се разрази малка, но много емоционална дискусия на […]
@ServiceGuard: Моля те, запознай се по-добре с идеологията и детайлите във функционалността на „това безполезно говно ASM“, преди да си вадиш изводи. Както казах вчера, ASM не е само опит за RAID.
А относно сравнението между ServiceGuard и CRS – от думите ти ясно личи, че, също като Хадес, ти си сисадмин и не се задълбаваш много в Oracle технологиите. Нормално е да имаме тотално различни гледни точки и в резултат – тотално различни мнения.
@yavor: Прочел съм нещо за него. Да вземем за пример твоят челен опит с тази тема – спиране на диск – пускане на диск /при което даже пак трябва да пъцкаш по SQL-а за да тръгне/ това ако го направя на сториджа даже няма и да се усети.
За сравнението – не съм точно сисадмин и нека не си правим изводите кой какво познава. Най ще ме радва да оутсоурсна всичко свързано с базата на ДБА-то и той да си цъка SQL-и дето управляват дисковете. Предлагам на Оракъл да пуснат в следващата версия да може и с SQL-и да си цъкаш по OS-a
ALTER SYSTEM REBOOT примерно.
Мога да се обзаложа, че системата ще искара седмица-две максимум.
VIP-a няма никакав проблем на го мести и ServiceGuard-а.
Всъщност имах проблем с CRS – при две активни инстанции и двата вип-а бяха отишли на първия нод и трябваше ръчно да ги оправям.
Hades, ако искаш да правиш active-pasive, тогава CRS не е твоя избор. Не е това идеята му и не за това е правен. За active-pasive ако искаш ползвай MSCS, все ми е тая.
Аз все още се надявам, макар и все по-вяло, да ми дадеш някакъв реален технически проблем, с който CRS би трябвало да се справя по-добре. Нещо, което не е направено добре, логиката му не е оптимална или пък липсва и би било полезно. Ако ми изреждаш бъгове или ми говориш, че съм олигофрен… не знам какво печелиш. Както писах вчера, имаме шанс да искаме неща от Oracle, за да се подобрят нещата и да ни е по-лесно и удобно. За това моля, опитай се да бъдеш поне малко конструктивен (ако можеш, де).
Абе Яворе,
Шматко проста, какво ми се чепиш за някакви Exadata и подобни лайна…Кажи си заплатката в МТЕЛ, стига си ни занимавал с глупости :Р
Е чети горе какво писах за поведението на CRS-а в определени случаи. Доста подробно описах конкретните случаи и последствията. Дори от metalink-а ти изрових конкретния doc и какво пише в него, повече от това не мога да направя…
@Petur: 🙂
@Hades: Извинявай, ама не останах убеден, че описаното от теб поведение може да бъде много по-добро. Кажи нещо по коментар 19, моля
Аз при успиване бих килнал SMON, той спира всички останали процеси и нищо не остава след него. После инстанцията сама се рестартира и си тръгва.
За съжаление при такова насилствено затваряне на БД могат да останат както разни успали се процеси, така и shared memory сегменти и семафори, които трябва да се чистят ръчно. E, може би могат да е изловят и програмно, но си е опасно.
А с VIP-а какво правим? Как да го прехвърлим към някой друг нод, като не се чуваме с тях? Е, може и да се чуваме през public интерфейса, но въпроса за failover на HB и целия private трафик към public интерфейсите още не е решен.
@yavor: Аз това съм го правил поне 4-5 пъти и не са ми оставали семафори и shared memory сегменти.
С VIP-a – private интерфейса трябва да ти е дублиран, ако са два нода може да имат сериина връзка и т.н. общо взето е добре да имаш и failover в tnsnames при клиента. тогава няма да имаш проблем с VIP-а.
А какво правим като ти падне interconnect switch-a ? 🙂
Хмм… Пак ще кажа за какво служи VIP-a. Първо, той е на public мрежата и няма много общо с interconnect switch-a. Второ, единствената cluster-related работа на VIP-а е при отпадане на някой нод, друг да вземе същия адрес и да започне да блъска reset на всяка TCP сесия. Т.е. настройката на failover в tnsnames при клиента така или иначе ти трябва.
Много хора си мислят, че като се прехвърли VIP адреса от нод А на нод Б, Б започва да се преструва, че е А и да обработва клиентските сесии през него. Това не е вярно. Той просто отговаря с reset за да може клиента веднага да си направи filover, без да се налага чакане на timeout (което понякога може да отиде до няколко минути).
Май трябва да драсна един отделен постинг за това. btw, с CRS можеш да си вдигаш и прости failover алиаси, които си работят така, както очакваш ти като падне един нод, просто някой друг му поема IP-то и отговаря от негово име. VIP-а е по-специален случай, както обясних.
@yavor: ти питаш как да се прехвърли VIP-a – аз ти отговарям през heartbeat по частния интерфейс.
Ама нали обсъждаме точно случая, когато private връзката е паднала. Ако interconnect-а си работи, изобщо нямаме проблем
@yavor при SG има едно понятие – cluster lock disk/quorum server той се използва точно при такива split brain ситуации. HACMP пък има възможност за директен heartbeat през shared disk. Общо взето може да се мине изобщо без Oracle CRS с малко доработки.
При CRS също има quorum, само че се нарича Voting disk. Използва се точно в обсъждания от нас случай, когато private interconnect-a отпадне. Тогава на voting disk-а всеки нод казва с кого има връзка и така се разбира коя е най-голямата група от нодове, която се виждат. Примерно ако имаме 8 нода, там се разбира, че едните 3 се виждат помежду си, и другите 5 се виждат. След това по-малката група се evict-ва, т.е. се рестартира.
„Директен heartbeat през shared disk“ – това е полезно само ако имаш active-pasive ресурси. CRS е направен за да поддържа RAC, неговата идеология е организирана около active-active. Както писах вчера, ако искаш да правиш active-pasive, CRS наистина не е твоя клъстеруеър.
Между другото, в началото (при OPS) не е имало cache fusion и блоковете са се разнасяли между нодовете точно чрез disk ping. Това, обаче, е доста бавно, особено сравнено с infiniband решенията. Ако имаш един сегашен клъстер с RAC и при отпадане на един нод заочнеш да използваш диска за private трафика, performance-а ти ще бъде по-лош от този на един standalone нод.
При HACMP е друго. Там няма кой-знае какъв трафик между нодовете освен HB и няма никакъв проблем да се разбират през private ethernet, през public връзката, през disk ping или даже по сериен кабел, ако трябва. Други цели – други решения.
> Лекциите на Зюмикс-а, няма нужда да ги слушам, след като
> видях че е избран за Oracle Admin на 2008-ма…дори няма да го
> коментирам….
Това не го разбирам, би ли пояснил?