ITBlog: Test macierzy Dell powervault md1000

Test macierzy Dell powervault md1000

depesz — Thu, 27 Sep 2007 17:04:00 +0200

Ostatnio dostaliśmy nową zabawkę do testów - nowiutkiego della powervault md1000. Co to takiego, zapytacie? Otóż jest to całkiem miły "das" (direct attached storage, czyli, upraszczając trochę, po prostu macierz) od Dell'a.
Egzemplarz, który testowaliśmy miał 15 dysków sas, każdy o pojemności 72gb i prędkości obrotowej 15000 rpm. Macierz ma być używana jako nośnik dla bazy danych, więc zanim zostanie użyta musieliśmy przeprowadzić testy (by wiedzieć co i jak podzielić na poszczególne dyski logiczne). Podłączyliśmy ją do wolnego serwera (także Dell'a, ale nieużywanego), którego parametry są "całkiem, całkiem" :

4 dwurdzeniowe xeon'y (3.4ghz)
32gb ram
2 wewnętrzne dyski, sas, 72gb, 15000 rpm, 72g zestawione w raid1

Testy przeprowadziliśmy przy pomocy bonnie++, procedura testowa była prosta:

zestawienie nowego raida
mke2fs -j (ext3)
zamontowanie partycji z opcjami noatime i nodiratime
uruchomienie bonnie++ z tymi opcjami:"-u nobody:nobody -f -s 65000,8192 -n 0 -x 3" (8192 gdyż taka jest wielkość strony w postgresie)
rezultaty dla każdego raida (-x 3!) były uśrednione

Wiedzieliśmy, że docelowo zostanie użyty raid10, więc testowaliśmy głównie różne jego kombinacje. Przeprowadziliśmy 2 oddzielne serie testów:

raid 10, czysto sprzętowy, używając 2, 4, 6, 8, 10, 12 i 14 dysków
raid 10, mieszany sprzętowo/software'owy - sprzęt był użyty do zrobienia 7 oddzielnych dysków logicznych, każdy z użyciem 2 dysków fizycznych spiętych w raid1, ale potem były one składane w jeden dysk logiczny przy pomocy software'owego raida (linux, raid0) w urządzenie na 4, 6, 8, 10, 12 i 14 dyskach fizycznych

Testy przeprowadzono z wyłączeniem read-aheada, zapisy były w trybie write-back, gdyż macierz jest wyposażona w pamięć z podtrzymaniem bateryjnym. Rezultaty są trochę dziwne (czerwona linia - raid10 czysto sprzętowy, zielona linia - rozwiązanie mieszane: sprzęt/software):

Jeśli wolisz wyniki w postaci tabelek:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	34820	12	25105	6	97459	9	436	1
4xraid10	95427	37	65661	19	246490	23	615	1
6xraid10	100367	39	70955	20	288188	27	672	1
8xraid10	165980	66	98887	29	423983	39	737	1
10xraid10	164195	64	96039	28	394442	36	618	1
12xraid10	185671	72	103271	30	414942	38	686	1
14xraid10	195349	76	104087	30	439088	40	821	2
2s0@2h1	86651	32	61836	18	251109	24	618	1
3s0@2h1	110977	42	79381	24	356231	34	708	2
4s0@2h1	120232	45	91988	28	391041	37	748	2
5s0@2h1	131024	50	92403	28	556601	55	788	2
6s0@2h1	123812	47	93563	28	482090	47	778	2
7s0@2h1	137513	53	100083	31	657221	65	839	2
2s0@6h10	160090	61	104375	32	482106	46	716	2
2s1@2h1	44373	16	25972	6	99071	10	651	1
13xraid5	222225	87	113040	32	392238	36	806	2
14xraid5	222690	87	114142	33	398201	36	809	2

Znaczenie kolumny name:

(\d+)xraid(\d+) - $1 dysków w czysto sprzętowym raidzie $2. przykładowo - 6xraid10 oznacza 6 dysków w sprzętowym raidzie 10
(\d+)s0@2h1 - $1 dysków logicznych (gdzie każdy dysk logiczny, to 2 dyski fizyczne spięte w sprzętowy raid1) połączone w software'owy raid0. przykładowo 5s0@2h1 oznacza 5 dysków logicznych (każdy z 2 napędów, w raid1) połączonych, dając razem raid 10 na 10 dyskach w układzie mieszanym sprzętowo/software'owym
2s0@6h10 - 2 dyski logiczne, każdy składający się z 6 dysków fizycznych połączonych w sprzętowy raid10, połączone w software'owy raid 0
2s1@2h1 - 2 dyski logiczne, każdy będący 2 dyskowym, sprzętowym, raidem 1, połączone w software'owy raid1. daje to 4 dyskowa macierz o pojemności pojedynczego dysku.

Jak widać, przetestowaliśmy kilka układów więcej niz pokazane jest to na wykresach powyżej, ale wszystkie pozostałe były jedynie testowe, bez realnego wpływu na jakiekolwiek decyzje. Dziwna sprawa - czysto sprzętowy raid wykazuje "schodki" w wydajności zapisów (i przepisywania danych). Przyrost wydajności był tylko wtedy, gdy ilość dysków była potęgą 2. W raidach mieszanych (sprzęt/software) nie było takiego efektu. Ponieważ macierz ma 15 dysków, zdecydowaliśmy się na użycie takiego layoutu:

1 dysk jako globalny hot-spare
2 diskowy raid1 (sprzętowy) na logi postgresa
8 dyskowy raid10 (sprzętowy) jako główna przestrzeń (tablespace) bazodanowa
4 dyskowy raid10 (sprzętowy) jako dodatkowa przestrzeń bazodanowa

Teoretycznie układ ten powinien zapewnić najlepszą wydajność, czy tak było? Po stworzeniu macierzy, założeniu systemów plików, przetestowaliśmy wydajność wszystkich 3 dysków logicznych jednocześnie. Wyników nie rozrysowywaliśmy, gdyż i tak nie miałoby to zbyt dużego sensu. Ale wyniki z testu można podać tabelarycznie:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	30875	12	15438	5	39867	5	224	1
2xraid1	32489	14	24037	7	99700	9	389	1
2xraid1	35096	13	24708	6	96969	9	383	0
4xraid10	41343	18	31910	11	61798	8	109	0
4xraid10	80630	34	35707	12	137488	18	306	1
4xraid10	40136	17	38388	12	147282	16	255	0
8xraid10	42376	18	37513	13	155740	19	302	1
8xraid10	156044	65	34153	11	177690	22	338	1
8xraid10	146096	61	71307	25	29568	3	154	0

(pokazano tu wyniki każdego testu, czyli po 3 wyniki dla każdej z partycji). Jak widać, wyniki są niższe od oczekiwanych. Dodatkowo, analizę utrudnia fakt, iż test macierzy 8xraid10 skończył się jako pierwszy (bo jest najszybsza), 4xraid10 skończył się trochę później, a 2xraid1 trwał i trwał, i trwał:)
Myślę, że wybraliśmy rozwiązanie optymalne przy tej macierzy i kontrolerze, ale tak czy inaczej zastanawiające jest czemu wydajność tak mocno jest powiązana z potęgami dwójki.

"Test macierzy Dell powervault md1000" by matrut

Fri, 22 Feb 2008 00:53:23 +0100

panowie z allegro przesiaknieci “sukcesem” sadza, ze stworzyli III armie Pattona ktora podbije europe srodkowo-wschodnia -> gratuluje podejscia, prawda BIGHard?

niestety jesli mowa silnikach bazodanowych niebagatelne znaczenie ma staz. ten w przypadku pgsql’a, oracle, db2 odgrywa czolowa role.

ciekawe dlaczego owa ‘armia’ zdecydowala sie migracje na oracle skoro mysql tak dobrze sobie radzil…. moze wiecej szczegolow technicznych niz tylko uskutecznianie dzichadu?

"Test macierzy Dell powervault md1000" by tomee

Sun, 27 Jan 2008 18:35:04 +0100

Troche kopa ta macierz ma, ale wyniki mnie nie porazaja. Por. http://tomee.heroin.pl/bonnie.html, zwl. ostatnie pozycje. Jaki system plikow, spytacie… no, na pewno nie ext3.

"Test macierzy Dell powervault md1000" by klolik

Wed, 14 Nov 2007 21:31:41 +0100

z niewielkiego doświadczenia wiem, że przesiadka z postgresa na mysql jest doznaniem wysoce irytującym dla każdego, kto używa czegoś więcej niż standardowe insert/update/select. triggerami i procedurami można dużo łatwiej zapewnić integralność bazy + cacheować pewne rzeczy, np. liczbę fotek każdego użytkownika ;) szczególnie jeśli zmiany wprowadza się przez różne API—lepiej niech dba o to baza, skoro i tak jest ostatnim ogniwem.

"Test macierzy Dell powervault md1000" by depesz@grono.net

Sat, 27 Oct 2007 17:16:18 +0200

@BIGHard:

ekhem. sorry – nie wiem jak jest w mysql’u, ale w postgresie dump daje snapshota. niezależnie od tego ile czasu trwa i ile innych operacji po drodze było.

z http://www.postgresql.org/docs/current/interactive/app-pgdump.html:

pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).

"Test macierzy Dell powervault md1000" by BIGHard

Fri, 26 Oct 2007 22:38:44 +0200

ja wiem ze dumpa da sie zrobic i na masterze – tak jak w mysqlu. chodzi mi raczej o to, ze jesli trwa dluzej niz jedna atomowa operacje, to nie masz backupu z danego momentu tylko nalozone operacje z paru godzin. a co jesli update trwa dluzej niz backup? dostaniesz wtedy np polowe tabeli przed update i polowe po – wlasnie dlatego slave – stop; dump; start – i masz dokladnie z danej chwili snapshot.

"Test macierzy Dell powervault md1000" by depesz@grono.net

Fri, 26 Oct 2007 08:57:03 +0200

@BIGHard:

śmiać się nie będę.

odpowiadając – slony działa całkiem fajnie i nie do końca widzę w nim tragedię – oczywiście, sporo rzeczy można zrobić lepiej, ale tak to każdy system można “wypunktować”, dodatkowo jest kilka innych rozwiązań replikacyjnio/klastrujących – polecam spojrzenie na pgpoola (do pewnych zastosowań świetne, ja osobiście nie przepadam), londiste (prostsza replikacja typu async master-slave), bucardo (async multi-master) czy pl/proxy. zwłaszcza ten ostatnio projekt jest bardzo interesujący, mimo (a może własnie dlatego), że nie jest replikacją.

backupy – normalnie. pg_dump tam gdzie trzeba, backupy wala tam gdzie się nadają. da się. pg_dump (w przeciwieństwie do niektórych innych baz danych) nie lockuje – co oznacza, że dumpa możesz robić w dowolnym momencie. oczywiście lepiej go zapuszczać na slave’ach, ale gdy trzeba to i na masterze pójdzie.

co do replikacji w mysql – sam nie testowałem. natomiast czytałem opisy i martwi mnie jej model działania – slave’y nie są zabezpieczone przed modyfikacjami (co jest fajnym feature’em bo daje możliwość zestawienia replikacji cyklicznej), multi-master cykliczny opiera się na założeniu (a przynajmniej tak zrozumiałem), że musisz sam (w aplikacji) dbać o kwestie konfliktów rzeczy typu indeksy unikatowe.

nie twierdzę, że mysql jest zły – po prostu znam lepiej postgresa, jego wady i zalety i jakoś przyjemnie mi się w nim pracuje.

co do oracle’a – to temat na inną świętą wojnę – ogólnie nie uważam by w zastosowaniach oltp przy tej (i dwóch następnych) skalach wielkości baz oracle miał jakąś istotną przewagę.

"Test macierzy Dell powervault md1000" by BIGHard

Thu, 25 Oct 2007 03:06:10 +0200

nie draznie, wdaje sie w rzeczowa dyskusje

"Test macierzy Dell powervault md1000" by barnaba@gentoo.pl

Wed, 24 Oct 2007 09:18:00 +0200

BIGHard nie drażnij depesza

"Test macierzy Dell powervault md1000" by BIGHard

Fri, 19 Oct 2007 23:26:02 +0200

bedziesz sie depeszu smial pewnie, ale powiem mysql :)

dlaczego? replikacja… w mysqlu jest natywna (jak robicie backupy bez repliki?) – zamiast slonia w postgresie, ktory jest tragedia…

chyba ze naprawde uzywacie trigerow i procedur, i bez nich swiat sie zawali – bo w kwestii wydajnosci bazy mysql radzi sobie calkiem calkiem.

bo na oracla, to jeszcze nie czas, prawda?

"Test macierzy Dell powervault md1000" by depesz@grono.net

Wed, 10 Oct 2007 12:53:21 +0200

@BIGHard:

Jak na razie ta pojemność w 100% wystarcza (z wystarczającym marginesem aby dane użytkowników nie były zagrożone). Dodatkowo – nikt nie mówił, że to jedyna macierz podpięta pod bazę, ani, że to jedyna baza.

Ciekawi mnie natomiast osobiście Twój stosunek do PostgreSQL’a. Jak rozumiem uważasz, że wybór tego silnika bazodanowego nie jest optymalny. Czemu? Jaki inny mógłbyś zasugerować? I czemu właśnie ten.

"Test macierzy Dell powervault md1000" by BIGHard

Mon, 08 Oct 2007 13:28:30 +0200

policzmy:

8 dyskow w raid10 po 72gb kazdy, daje nam pojemnosc 4*72gb = 288gb na baze

tylko? phi…

pozatym – postgres??

"Test macierzy Dell powervault md1000" by jaro

Tue, 02 Oct 2007 19:34:55 +0200

tylko trzeba sobie przypomniec kilka wykladow i wszysto w miare zrozumiale :)

"Test macierzy Dell powervault md1000" by juhu

Tue, 02 Oct 2007 02:09:00 +0200

Użytkownicy grona zapewne wszystko doskonale zrozumieli. Zresztą fotka ma cztery takie maszynki.