Temat: +ASM i dyski

Witam,

Konfiguruję właśnie RACa na ASMie. Jako storage wykorzystuje macierz z której mam zaprezentowane po FC - 2 dyski. Mam pytanie, czy jest sens rozdzielać np. logi na osobny dysk ASMowy, a na drugi dane ? Czy lepiej zrobić jeden większy dysk i tam trzymać dane + archivelogi + reszta plików potrzebnych instancjom?

Skłaniam się raczej za drugim rozwiązaniem, ale chciałbym poznać Wasze opinie.
Dziękuję i pozdrawiam,
Kuba,

Temat: +ASM i dyski

2 dyski czy 2 LUNy zbudowane z kilku dyskow?
Ja bym poszedl w kierunku mirroringu, bedziesz mial lepsze SLA przy awarii jednego dysku ;)

Temat: +ASM i dyski

O bezpieczeństwo danych i wydajność dba macierz, więc nie tworzę mirorringu podczas dodawania dysków do ASM'a. Mam typ redundancji external, bo od tego jest macierz, aby się tym zajmowała.

Ja mogę stworzyć z zaprezentowanych dysków dwie diskgrupy i pytanie moje jest, czy tak zrobić. Do jednej wrzucić np. archive logi, a do drugiej datafile'e i inne pliki.

Osobiście wolałbym mieć zaprezentowany 1 większy dysk i na nim mieć wszystki, tj. arch logi, dane itp.

W zasadzie to sobie sam odpowiedziałem na swoje pytanie;)

Temat: +ASM i dyski

Jezeli wystawiamy LUNy z macierzy to generalnie mozna wszystko walnac na jednym dysku ASM, jednak aby bylo bardziej elegancko to jednak +ASM1(DANE) i +ASM2(RESZTA).

Temat: +ASM i dyski

Zbigniew G.:
Jezeli wystawiamy LUNy z macierzy to generalnie mozna wszystko walnac na jednym dysku ASM, jednak aby bylo bardziej elegancko to jednak +ASM1(DANE) i +ASM2(RESZTA).

Czyli żeby było elegancko to należy dołożyć sobie i innym pracy oraz skomplikować system :)

:P

W przypadku dobrej macierzy nie ma sensu rozdzielać logów i danych. Dotyczy to zwłaszcza macierzy, które mają duży cache na poziomie > 512MB. System będzie prostszy, będzie miał mniej elementów podlegających prawdopodobieństwu awarii i ewentualnemu konfigurowaniu podczas odtwarzania.

Być może byłaby drobna różnica w wydajności, gdyby te LUNy były także na osobnych poolach (grupach) dyskowych. Jeśli jednak myślisz o cięciu jednej grupy na części to nic to nie da.

Temat: +ASM i dyski

Argument o prostocie system jest niepodważalny. Faktem jest, że im mniej złożony system to mniejsza prawdopodobieństwo wystąpienia awarii, popełnienia błędu etc.

Tak, to dobra macierz i ma duży cache;)

Dziękuję za odpowiedź,

Temat: +ASM i dyski

ASM jest na tyle elastyczny, że tak długo, jak długo masz dostępne 2 dyski, zawsze możesz jeden wyjąć z utworzonej już grupy, zrobić nową grupę i dodać do niej ten dysk, lub zrobić operację odwrotną - i wszystko to online :)

Na dwóch systemach na których pracuję archivelogi mają oddzielną grupę asm-ową, ale rzeczywiście nie jest to warunek konieczny i już zdarzyło mi się zmieniać przez to log_archive_dest na grupę z danymi kiedy +ASMARCH się przypchała ;)Katarzyna Bielecka edytował(a) ten post dnia 24.02.09 o godzinie 10:21

Temat: +ASM i dyski

Krzysztof P.:

Zbigniew G.:
Jezeli wystawiamy LUNy z macierzy to generalnie mozna wszystko walnac na jednym dysku ASM, jednak aby bylo bardziej elegancko to jednak +ASM1(DANE) i +ASM2(RESZTA).

Czyli żeby było elegancko to należy dołożyć sobie i innym pracy oraz skomplikować system :)

:P

Czesc,

Czemu skomplikowac ? Czy dwa luny z macierzy to wieksza komplikacja niz jeden lun ?

Ja osobiscie bym zalecal osobno archivelogi a osobno dane.
W przypadku wywalenia sie w powietrze jednej grupy druga moze przezyc i np. mozemy miec wiecej archivelogow niz na tasmie.

A przy okazji jesli mamy wiecej niz jeden kontroler FC to dwa luny umozliwia rozlozenie obciazenie pomiedzy 2 kontrolery.

pozdrawiam,
Marcin Przepiorowski

Temat: +ASM i dyski

Marcin Przepiórowski:
Czemu skomplikowac ? Czy dwa luny z macierzy to wieksza komplikacja niz jeden lun ?

Wszystko co wiąże się z większym skomplikowaniem instalacji to jest komplikacja :)

W przypadku wywalenia sie w powietrze jednej grupy druga moze przezyc i np. mozemy miec wiecej archivelogow niz na tasmie.

A przy okazji jesli mamy wiecej niz jeden kontroler FC to dwa luny umozliwia rozlozenie obciazenie pomiedzy 2 kontrolery.

Co by było gdyby ... W praktyce zazwyczaj pada albo cała grupa dyskowa w macierzy albo cała macierz. Oba luny z jednej fizycznej grupy polecą jednocześnie. Jednak nie spotkałem się jeszcze z awarią całej puli bo oznaczałoby to najczęściej minimalnie jednoczesną awarię dwóch dysków. Jeśli już to pada kontroler.

Jeśli ktoś myśli, że obecność drugiego zapasowego kontrolera coś daje to może się mylić :) Spotkałem się już z przypadkiem, gdzie awaria kontrolera spowodowała totalne posiekanie danych na dyskach i pomimo, że zapasowy kontroler się włączył to nie było już czego ratować.

Co do rozłożenia obciążenia ...

Kontrolery w typowych macierzach i NASach pracują w dwóch trybach: active/passive, a w tych wyższej półki active/active. A tylko w konfiguracji active/active będziesz mógł skorzystac z benefitu jaki daje dwie karty FC. To wszystko zależy jednak ściśle od sprzętu czyli budżetu. "Highendowe" maszyny i macierze umożliwiają agregację portów FC, trzeba tylko odpowiednio skonfigurować DMP.

Temat: +ASM i dyski

Krzysztof P.:

Marcin Przepiórowski:
Czemu skomplikowac ? Czy dwa luny z macierzy to wieksza komplikacja niz jeden lun ?

Wszystko co wiąże się z większym skomplikowaniem instalacji to jest komplikacja :)

W przypadku wywalenia sie w powietrze jednej grupy druga moze przezyc i np. mozemy miec wiecej archivelogow niz na tasmie.

A przy okazji jesli mamy wiecej niz jeden kontroler FC to dwa luny umozliwia rozlozenie obciazenie pomiedzy 2 kontrolery.

Co by było gdyby ... W praktyce zazwyczaj pada albo cała grupa dyskowa w macierzy albo cała macierz. Oba luny z jednej fizycznej grupy polecą jednocześnie. Jednak nie spotkałem się jeszcze z awarią całej puli bo oznaczałoby to najczęściej minimalnie jednoczesną awarię dwóch dysków. Jeśli już to pada kontroler.

Witam,

Co by bylo gdyby - to wlasnie taka zabawa dla architektow ;)
(niestety glownie ograniczona budzetem) :-)

No ja juz widzialem w zyciu wylot calej grupy dyskowej (jednej z wielu) i czesciowy wylot bazy z plikow polozonych na tej grupie.

Pozatym dochodzie jeszcze jedna rzecz ktora pominales, jak wylot grupy zwiazany z bledami w ASM-ie - wkoncu to tylko soft wiec na pewno ma bledy. A jak pokazuje doswiadczenie to wylot moze nastapic w momencie jak akurat backup na tasmy sie nie udal ;)

Znaczy moja generalna zasada jest taka - jak cos jest czescia backupu to powinno byc jak najbardziej odzielone od systemu online.
Oczywiscie dochodza to tego pieniadze ... ale ja zawsze staram sie trzymac tej zasady.

pozdrawiam,
Marcin Przepiorowski

Temat: +ASM i dyski

Krzysztof P.:

Marcin Przepiórowski:
Czemu skomplikowac ? Czy dwa luny z macierzy to wieksza komplikacja niz jeden lun ?

Wszystko co wiąże się z większym skomplikowaniem instalacji to jest komplikacja :)

W przypadku wywalenia sie w powietrze jednej grupy druga moze przezyc i np. mozemy miec wiecej archivelogow niz na tasmie.

A przy okazji jesli mamy wiecej niz jeden kontroler FC to dwa luny umozliwia rozlozenie obciazenie pomiedzy 2 kontrolery.

Co by było gdyby ... W praktyce zazwyczaj pada albo cała grupa dyskowa w macierzy albo cała macierz. Oba luny z jednej fizycznej grupy polecą jednocześnie. Jednak nie spotkałem się jeszcze z awarią całej puli bo oznaczałoby to najczęściej minimalnie jednoczesną awarię dwóch dysków. Jeśli już to pada kontroler.

Jeśli ktoś myśli, że obecność drugiego zapasowego kontrolera coś daje to może się mylić :) Spotkałem się już z przypadkiem, gdzie awaria kontrolera spowodowała totalne posiekanie danych na dyskach i pomimo, że zapasowy kontroler się włączył to nie było już czego ratować.

Co do rozłożenia obciążenia ...

Kontrolery w typowych macierzach i NASach pracują w dwóch trybach: active/passive, a w tych wyższej półki active/active. A tylko w konfiguracji active/active będziesz mógł skorzystac z benefitu jaki daje dwie karty FC. To wszystko zależy jednak ściśle od sprzętu czyli budżetu. "Highendowe" maszyny i macierze umożliwiają agregację portów FC, trzeba tylko odpowiednio skonfigurować DMP.

Macierze to jedne z najmniej awaryjnych urzadzen wszystko w nich ma pelna redundancje, dodatkowo sprzet np. EMC ma Live Migration (czy jakos tak) gdzie mozemy z poziumu macierzy przeniesc pule na ktorej dziala baza na inna pule i to wszystko na dzialajacym systemie. Dodatkowo jak mamy kase mozemy sobie podpiac dwie macierze i kazda lune mirrorowac na OSie (z jednej i drugiej macierzy). Generalnie jesli sie przechowuje cenne dane i ma "pare groszy" to mozna dosc znacznie zmniejszyc ryzyko utraty danych.

ZG

Temat: +ASM i dyski

Zbigniew G.:

Macierze to jedne z najmniej awaryjnych urzadzen wszystko w nich ma pelna redundancje, dodatkowo sprzet np. EMC ma Live Migration (czy jakos tak) gdzie mozemy z poziumu macierzy przeniesc pule na ktorej dziala baza na inna pule i to wszystko na dzialajacym systemie. Dodatkowo jak mamy kase mozemy sobie podpiac dwie macierze i kazda lune mirrorowac na OSie (z jednej i drugiej macierzy). Generalnie jesli sie przechowuje cenne dane i ma "pare groszy" to mozna dosc znacznie zmniejszyc ryzyko utraty danych.

A zaczalo sie od tego jak to zrobic najprosciej i nie komplikowac ;)

Generalnie zgadzam sie ze macierze to dosc niezawodne skrzynki,
(dosc oczywiscie nie znaczy w 100 % - nie wiem moze ja mam pecha
ale widzialem kilka czesciowych padow macierzy roznych vendorow)
ale jakos wszyscy zapomniaja ze to co sie zapisuje na macierzy zalezy od systemu operacyjnego plus w tym przypadku bazy danych plus ASM. Wiec jesli poleci nam cos na tym poziomie to zaden RAID
czy inne zabawki na poziomie macierzy nie pomoga.

Pytanie brzmi tak - czy jesli strace pol bazy to reszta ma wogole szanse byc potrzeba czy nie ? jesli tak - podzial na kilka dyskow, grup, czegokolwiek zwieksza szanse przezycia.

Mysle ze na pytanie czy backup i baza produkcyjna ma byc na tej samej macierzy wogole nie wchodzi w gre - oczywiscie taki backup podreczy dyskowy - bo naprawde bezpieczny backup to jest tylko na tasmie (tasmach) a kazda z kopii w roznych lokalizacjach ;)
Pytanie kto za to placi ? ;)

pozdrawiam,
Marcin PrzepiorowskiMarcin Przepiórowski edytował(a) ten post dnia 25.02.09 o godzinie 16:23

Temat: +ASM i dyski

Jakub Hajek:
Witam,

Konfiguruję właśnie RACa na ASMie. Jako storage wykorzystuje macierz z której mam zaprezentowane po FC - 2 dyski. Mam pytanie, czy jest sens rozdzielać np. logi na osobny dysk ASMowy, a na drugi dane ? Czy lepiej zrobić jeden większy dysk i tam trzymać dane + archivelogi + reszta plików potrzebnych instancjom?

Skłaniam się raczej za drugim rozwiązaniem, ale chciałbym poznać Wasze opinie.

Przy dwóch dyskach taka zabawa nie ma sensu. Jedna grupa dyskowa na całość bazy danych. Po to jest ASM żeby się nie bawić w opowieści z czasów wersji 7/8 (pamiętaj adminie młody rozdziel logi, od plików etc).
Plusy:

1. Masz dostępną przy odczytach całość IO per sec jaki ten konkretny sprzęt Ci daje.
2. Masz dostępną cały zapas dysków w jednym worku. Bez kombinowania "baza mi puchnie, a storage będzie za tydzień to upchnę dwie przestrzenie na grupie pod archive logi".
3. Oracle od jakiegoś czasu tłucze do łebków use SAME i wyjątkowo się to przy ASM'ie zgadzam ;-)

Różne grupy dyskowe mają sens jedynie jeżeli chcesz podzielić zasoby dyskowe lub przepustowość systemu dyskowego między różne bazy/projekty/moduły systemu (w tym ostatnim zrabialne jeżeli masz rozdział obiektów między różne przestrzenie tabel).

Nie wiem jak jest z ilością generowanych archive logów, jeżeli niezbyt dużo pytanie czy potrzebujesz je wrzucać na ASM'a ??
FS z macierzy i tak ma redundancję, a upraszcza się kwestia backupowania (z ASM'a to tylko rman może jeszcze dbms_file_transfer ale to egzotyka). Zresztą jakiegoś współdzielonego fs'a między węzłami RAC'a będziesz potrzebował bo o ile pamiętam voiting dysków to na ASM'ie nie położysz :-)

Argument o tym że jak Ci padnie ASM to pofruną archive logi raczej słaby:
1. Nowoczesne macierze jak ktoś zauważył naprawdę są mało awaryjne.
2. Archive logi są po to żeby było czym bazę dokręcać więc raczej jak najmniej ich leży z bazą tylko są backupowane do zdalnej lokalizacji. Tu druga grupa dyskowa średnio Ci się przyda jak masz ASM'a który chodził na maszynie która się właśnie dopala :-D , już lepszy fs mapowany z innej maszyny.
3. Sam pad ASM nie jest żadnym zagrożeniem, można nawet zaorać proces cssd (localconfig delete i troszke użwania rm), ale dopóki na maszynie są widocznej dyski wystawione do ASM'a i nic nie pojechało im nagłówków to rekreacja konfiguracji ASM'a (localconfig add, rott.sh i spółka) powoduje, że podnosisz ASM i baza dalej jest na tych dyskach (przy RAC'u nieco więcej zabawy)

I jeszcze jedno z własnego doświadczenia wiem że 2 dyski do ASM'a to słabo dostaje kopa tak od 5-6 sztuk dopiero (nawet jeżeli mówimy o lunach rozsypanych po całej macierzy to i tak lepiej wystawić 10x40 GB niż 4x100GB), tyle że przy RAC'u o ile nie ma sprzętowego klastra to raw dyski z maciorki się wystawiało o ile dobrze pamiętam (możliwe że źle bo się w kwestii stawiania czegoś takiego od zera na świeżych maszynach "nieco" się otłuściłem i rozleniwiłem)

uff tyle :-]

Literówki RiP :-]Andrzej P. edytował(a) ten post dnia 06.03.09 o godzinie 09:34

Temat: +ASM i dyski

Andrzej P.:
Nie wiem jak jest z ilością generowanych archive logów, jeżeli niezbyt dużo pytanie czy potrzebujesz je wrzucać na ASM'a ??
FS z macierzy i tak ma redundancję, a upraszcza się kwestia backupowania (z ASM'a to tylko rman może jeszcze dbms_file_transfer ale to egzotyka). Zresztą jakiegoś współdzielonego fs'a między węzłami RAC'a będzie potrzebował bo o ile pamiętam voiting dysków to na ASM'ie nie położysz :-)

Voting dyski i ocr można wrzucić na raw devices, dlatego kolejny fs nie jest potrzebny.

Ale zgadzam się, archive logi nie muszą iść na macierz, chociaż ja i tak wolę trzymać je oddzielnie od reszty plików bazy, bo wtedy jak się przypchają to tylko one. Teoretycznie nie powinno mieć takie przypchanie wpływu na bazę, ale ...

Ale w sumie kolega już chyba dawno tą bazę postawił :)

Temat: +ASM i dyski

Katarzyna Bielecka:

Voting dyski i ocr można wrzucić na raw devices, dlatego kolejny fs nie jest potrzebny.

Ale zgadzam się, archive logi nie muszą iść na macierz, chociaż ja i tak wolę trzymać je oddzielnie od reszty plików bazy, bo wtedy jak się przypchają to tylko one. Teoretycznie nie powinno mieć takie przypchanie wpływu na bazę, ale ...

Ale w sumie kolega już chyba dawno tą bazę postawił :)

Dziękuję za cenne uwagi. :) Rac postawiony. Skończyło się na jednym dużym dysku, gdzie spoczywają dane + reszta plików, oczywiście w ASM.

Vote i OCR mam na OCFSie, bo z raw devicami miałem taki problem, że po restarcie maszyny musiałem zmieniać im właściciela na oracle:dba, co wiązało się z wpisami w rc.local, a to mi się nie podobało. Z OCFSem nie mam takiego problemu i jest OK.

BTW, to pierwszy raz stawiałem bazę w trybie FAILOVER=ON, LOAD_BALANCE=OFF i przy instancjach PRIMARY / SECONDARY czyli active_instance_count=1. Działa bardzo ładnie i przełącza się w przypadku awarii bazy, node'a, czy też listenera.

pozdrawiam,

Temat: +ASM i dyski

Jakub Hajek:
Vote i OCR mam na OCFSie, bo z raw devicami miałem taki problem, że po restarcie maszyny musiałem zmieniać im właściciela na oracle:dba, co wiązało się z wpisami w rc.local, a to mi się nie podobało. Z OCFSem nie mam takiego problemu i jest OK.

A z ASM jakim to cudem nie masz takiego problemu ? Przecież to też jest "niby" raw device.

Do takich "myków" zmienia się konfigurację udev, albo dodaje odpowiedni skrypt, który zmienia właściciela przed wywołaniem /etc/init.d/oracleasm

Temat: +ASM i dyski

Krzysztof P.:

A z ASM jakim to cudem nie masz takiego problemu ? Przecież to też jest "niby" raw device.

Do takich "myków" zmienia się konfigurację udev, albo dodaje odpowiedni skrypt, który zmienia właściciela przed wywołaniem /etc/init.d/oracleasm

Fakt, /etc/init.d/oracleasm zmienia właściciela na wskazanego podczas configure, ale przy VOTE i OCR miałem z tym problemy, że po restarcie nie zmieniał, więc nie zagłębiałem się w temat i te dyski mam na OCFSie.
Generalnie chciałem mieć zgodnie z dokumentacją, a jedną z opcji jest OCFS, więc nie widzę problemu.

Pracując jako SysAdm robiłem masę "hacków" w systemach, a tu chcę mieć porządek;)

Pozdrawiam,

Temat: +ASM i dyski

Jakub Hajek:
podczas configure, ale przy VOTE i OCR miałem z tym problemy, że po restarcie nie zmieniał, więc nie zagłębiałem się w temat i te dyski mam na OCFSie.

Zajrzyj do katalogu /etc/udev.d/ i przyjrzyj się plikom, które tam istnieją. Dodanie jednej/dwóch linijek nie będzie trudne. To tak na przyszłosc :)

Temat: +ASM i dyski

Krzysztof P.:
Zajrzyj do katalogu /etc/udev.d/ i przyjrzyj się plikom, które tam istnieją. Dodanie jednej/dwóch linijek nie będzie trudne. To tak na przyszłosc :)

Znam udev.d, ale dziękuje za wskazówki. :)

BTW, to o zmianie w właściciela raw deviców w rc.local piszę dokumentacja na stronach Redhata:) Ale to poza tematem...

Temat: +ASM i dyski

Jakub Hajek:

Krzysztof P.:
Zajrzyj do katalogu /etc/udev.d/ i przyjrzyj się plikom, które tam istnieją. Dodanie jednej/dwóch linijek nie będzie trudne. To tak na przyszłosc :)

Znam udev.d, ale dziękuje za wskazówki. :)

BTW, to o zmianie w właściciela raw deviców w rc.local piszę dokumentacja na stronach Redhata:) Ale to poza tematem...

Witam,

No niestety 2 dni spedzone na proszeniu udev-a zeby zmienil mi prawa na multipathowych urzadzeniach w RH 5 skonczyly sie fiaskiem i zgodnie z bugzilla RedHat-a wszystkio jest po bozemu w /etc/rc.local ;)

A nawiazujac do problemu RAC-a i ASM-a - dzieki ASMowie mozna jest juz pozbyc raw device-ow co powoli zaczynalo byc upierdliwe jesli mowimy o Linuxie. Od wersji 10g cos tam mozna tez juz vote i ocr postawic na urzadzeniu blokowym, chodz wymaga to zabawy bo OUI jeszcze o tym nie wie.

Oczywscie zgadzam sie z archy mozna trzymac na wspolnym zdalnym filesystemie ale co z przypadku RAC-a i Oracle SE ? nie wolno nic tylko ASM :-(

Co do rozdzialu archow od plikow danych - czy trzymanie ich razem z danymi ma jeszcze jakies plusy oprocz wygody admina ?
Pytam z Ciekawosci bo kilka minusow dalo sie znalesc.

Moze zrobimy sonde, kto jak trzyma archy ?

ps.
Swoja droga kolo 2003 roku czytalem opracowanie chyba IDC
czy czegos podobnego ze 56 % baz na swiecie nie ma backupow ;)
Czyzby ludzie az tak wierzyli producentom macierzy ??

pozdrawiam,
Marcin Przepiorowski