Databáze přes NFS

16. 4. 2010 | Mark Stopka | Sítě | 20468×

Stále vyšší tlak zákazníků na cenu, dostupnost a kvalitu vede společnosti k implementaci různých řešení. Fibre Channel sítě jsou drahé, vyžadují více kvalifikovaných lidí (málo administrátorů ethernetových sítí má znalosti o FC fabric) a vybudování separátní storage sítě (či dokonce použití produkční nebo záložní sítě k přenosu storage dat) může poskytnout mnoho úspor.

Obsah

• Proč centralizové uložiště?
• Proč ne FC/SAN?
• Proč NFS?
• Jmenuji se Network File System, těší mě
  • NFSv1 a NFSv2
  • NFSv3
  • NFSv4
• Co na to distributoři databází?
  • Oracle DirectNFS (dNFS)

Mám nějaké zkušenosti s implementací databázových systémů po NFS (převážně SAP nad Oracle databází, nicméně i jiné), a proto bych se s vámi o ně chtěl podělit.

Proč centralizové uložiště?

V „domácím“ prostředí, kde se pro databáze používá DAS (Direct Attached Storage), dokáže spolehlivé centralizované úložiště přinést mnoho výhod, centralizaci úložných kapacit, zjednodušené kapacitní plánování, zjednodušenou údržbu a vyšší výkon. Na druhou stranu samozřejmě centralizované úložiště přináší nový single point of failure (bod selhání); pokud přijdete o síťové připojení k úložišti, nebo dokonce o celé úložiště, máte problém. Proto je při návrhu úložného systému potřeba dbát na patřičný redundantní návrh, například se inspirovat návrhem Zdeňka Burdy, případně se obrátit na nějakého spolehlivého distributora úložných řešení.

Proč ne FC/SAN?

Peníze, flexibilita a ještě jednou peníze, to je cena za použití FC/SAN centralizovaného storage řešení. SAN (Storage Attached Network) infrastruktura nabídne skvělý výkon, nicméně náklady na její vybudování jsou vysoké (jen takové jedno FC HBA stojí 10 000, ale potřebujete dvě, protože si nemůžete dovolit ztratit přístup ke svému úložišti jen kvůli závadě na HBA, a kvalitní FC fabric switche jsou dražší než kvalitní ethernetové switche). Stejně tak vysoké jsou i náklady na údržbu takovéto sítě. Jak již jsem uvedl v úvodu článku, pro správu FC fabric potřebujete většinou další lidi, protože běžní síťoví administrátoři nemají o FC sítích potuchy.

Prostě vysoká spolehlivost něco stojí a ne každý si to může/chce v dnešní době dovolit. Navíc za stejnou cenu, za kterou dokážete vybudovat FC/SAN síť, dokážete také vybudovat vysoce spolehlivou ethernetovou síť se srovnatelným výkonem, kterou navíc můžete použít i na něco více než jen storage traffic. Používat jako centralizované úložiště něco na bázi FC/SAN je mimo finanční možnosti většiny malých společností, přestože by jim centralizace úložných kapacit pro jejich data velice prospěla.

Proč NFS?

Důvod, proč byl zvolen protokol NFS, je poměrně prostý: NFS je protokol jednoduchý na implementaci a podporují jej všichni vendoři podnikového NAS (Network Attached Storage) hardwaru. Jedná se také o léty ověřený protokol, který na druhou stranu umí v ledasčem zklamat a překvapit. Stejně jako každý nástroj i tento by se měl používat s rozvahou. V prostředí malých společností je NFS (případně iSCSI) asi jediná možnost, kterou se společnost může vydat v případě, že by chtěla své úložné kapacity centralizovat.

V podnikovém prostředí se však cestou NFS vydávají také a mnohdy jej preferují oproti Fibre Channel SAN (Storage Attached Network), i když už mají SAN infrastrukturu vybudovanou. Nemají zatím dostatečnou důvěru v FCoE a investiční náklady do 8Gb/s FC fabric by byly obrovské, proto si je chtějí odpustit alespoň pro ty méně kritické systémy. Ať už jsou důvody jakékoli, děje se to, a proto by byla škoda o tom nic nevědět.

Jmenuji se Network File System, těší mě

NFSv1 a NFSv2

Protokol NFS vyvinula společnost Sun Microsystems v roce 1984, aby umožnila uživatelům přístup k datům na síťovém úložišti stejným způsobem, jakým k nim přistupují v případě lokálních disků. První verze NFSv1 nikdy nespatřila světlo světa mimo Sun Microsystems, sloužila pouze k interním experimentálním účelům. Druhá verze NFS – NFSv2 se objevila v březnu 1984 v podobě RFC 1094 a na transportní vrstvě podporovala jen UDP (User Datagram Protocol) – fungovala tedy zcela bezstavově. Stejně tak maximální velikost souboru byla 2^31 bytů (používal se signed 32 bit offset), tedy 2 GB a maximální velikost READ/WRITE operace byla 8 kB.

NFSv3

NFSv3 přišla na svět v červnu roku 1995 v podobě RFC 1813 a novinkou byla podpora větší velikosti souborů (offset je nyní unsigned 64 bit int) a velikost největšího souboru tak (pokud se spokojíme s 2^64) nyní záleží na serveru a na tom, jaký používá souborový systém. NFSv3 také přichází s podporou asynchronních zápisů na straně serverů, což zvyšuje výkon při zápisu. Nejdůležitější změna však byla pravděpodobně podpora pro protokol TCP na transportní vrstvě. Tímto začalo být možné NFSv3 více používat i například v prostředí sítí WAN (Wide Area Network). Nicméně, dovolil bych si podotknout, že někteří distributoři nabídli podporu pro TCP i pro NFSv2, nikoliv však SUN, ten přidal podporu pro TCP u NFSv2 až s přidáním podpory pro TCP s NFSv3.

Protokol NFSv3 je v současné době pravděpodobnější nejpoužívanější implementace NFS. A to i v případě databázových aplikací, přestože se stále jedná o bezstavový protokol (i nad stavovou transportní vrstvou TCP).

NFSv4

V listopadu 2000 byl představen protokol NFS ve své čtvrté verzi, a to v podobě RFC 3010, který byl následně revidován v dubnu 2003 prostřednictvím RFC 3530. Jeho vývoj byl značně ovlivněn existencí jiných síťových protokolů, jako je CIFS (Common Internet File System) od Microsoftu (který na Linuxu implementuje projekt SAMBA). NSFv4 je první verze, kterou vydala Internet Engineering Task Force, poté co ji SUN předal kontrolu nad protokolem. V této verzi NFS může být protokol již plně stavový. Nicméně ještě nedávno většina implementací NFSv4 nebyla zrovna… no, spolehlivá. Nicméně časy se mění a NFSv4 vidím jako budoucnost pro databázové i jiné aplikace, které vyžadují dobrý poměr cena/(výkon+spolehlivost).

Co na to distributoři databází?

Minimálně společnost Oracle si uvědomuje význam NFS v databázových prostředích, a proto je ve verzi Oracle 11g k dispozici vlastní implementace Oracle DirectNFS (dNFS), ostatně tento přístup je pro Oracle běžný. Když byla důležitá správa paměti, Oracle šel na to cestou „tak mi dejte stránky paměti a já se o ně budu starat sám“. Nyní, když je důležitý výkon NFS, Oracle chce čistý TCP/IP socket, on už se o vygenerování optimálního NFS requestu postará sám. Ostatní databáze tuto myšlenku až tak nepodporují, nicméně většina z nich umí více či méně dobře po NFS fungovat.

Oracle DirectNFS (dNFS)

Důvodů pro vývoj Direct NFS bylo několik, předně se instalace databáze Oracle s NFS začaly rozšiřovat, na což musel Oracle nějak zareagovat. Jeden z problémů při použití kernelového NFS je, že spousta administrátorů neví, jak vlastně NFS pro dobrý výkon v databázových aplikacích nastavit, což vede k nežádoucímu dopadu na výkon i spolehlivost. Dále pak neuspokojivá implementace NFS ve Windows a odstranění dvojitého cachování dat. Při použití kernelového NFS dochází ke cachování informací jak v prostoru kernelu, tak v uživatelském prostoru v samotné databázi. Pokud je NFS a databáze více provázaná, k dvojitému cachování již nedochází, což vám umožňuje dát databázi k dispozici více paměti.

Konfigurace dNFS se ukládá v souboru $ORACLE_HOME/dbs/oranfstab nebo si ji dNFS umí načíst přímo ze souboru /etc/mtab. Syntaxe konfiguračního souboru oranfstab je následující:

server: jméno serveru
path: první ip adresa/fqdn
path: druhá ip adresa/fqdn
export: /vol/oradata mount: /mnt/oradata

Položka server určuje jméno serveru, položky path určují, na kterých IP adresách je možné daný server najít. dNFS umí i bez využití bondingu/port allocation/etherchannelu využít více redundantních linek k přístupu ke storage systému a zvýšit tak síťovou propustnost. Takovýchto cest ke storage systému můžete mít až 4 – slouží jak pro zvýšení výkonu, tak ke zvýšení odolnosti proti výpadkům (za předpokladu dobrého síťového návrhu). Položka export určuje zdrojovou cestu, položka mount ji doplňuje o cíl, kam má být zdroj v hierarchii souborového systému připojen.

Ve výchozí konfiguraci není Oracle Direct NFS zapnuto, jeho zapnutí provedete jednoduše pomocí příkazů:

cd $ORACLE_HOME/lib
mv libodm11.so libodm11.so_stub
ln -s libnfsodm11.so libodm11.so

Více podrobných informací, včetně výkonnostních benchmarků, naleznete v Oracle Whitepaper – Oracle Database 11g Direct NFS Client (PDF).

Příště

V dokončení článku popíšu postřehy z implementace databáze Oracle přes NFS.

       

Komentáře

[Foo Bar]

No to je fujtajfl. Proc misto FC nepouzit iSCSI? Podle me je NFS na ukladani souboru databaze naprosto nevhodne, coz jde IMHO videt i z toho, ze Oracle obchazi klientskou implementaci a masti sito sami (pravdepodobne proto, ze NFS pouzivaji nejakym specifickym zpusobem, aby zajistili synchronizaci dat).

[okbob]

Minimálně pro PostgreSQL se NFS nedoporučuje - pokud někdo nechce přijít o data.

[danysek]

Pripadne existuji (draft) standardy a implementace FC over ethernet ... napr. www.open-fcoe.org.

[Käyttäjä 11133]

FCoE už není draft, ale jak dlouho, že? :)

[Andrej]

Preco miesto FC nepouzit iSCSI? Jeden dovod ma napada hned - iSCSI = block device, NFS = file sharing. Takze ak chcem vyuzit vyhodu zdielaneho uloziska pre N Oracle serverov a nechcem konfiguraciu komplikovat uloziskom typu Oracle ASM (mimochodom jediny certifikovany clusterfilesystem v pripade 2 nodoveho RAC clustra s licenciou Standard Edition) a samozrejme Oracle Clusterware (ASM vyzaduje beziace Cluster Synchronization Services), NFS mi pripada ako velmi jednoduche riesenie.

[Xerces]

Moje první reakce byla WTF!? A snad proto jsem se pustil do čtení. Ale každopádně článek mi příjde zajímavej. Alespoň je vidět, že cesty boží jsou nevyspytatelný a praxe je holt praxe.

[pasmen]

Pro Oracle starší než 11g to není? Já jen že jsem ještě neviděl SAP nad 11g...

[Käyttäjä 11133]

Ne, pro starší než 11g to není, ale to přece neznamená, že nemůžeš použít kernelové NFS, že...

[miky]

No, vzhledem k tomu, ze Oracle 9i a 10g ma pri pouziti NFS problemy docela problemy pri zalohovani (recovery database pres rman na NFS vetsinou nedopadne dobre - a bohuzel to chovani neni moc deterministicke), takze bych s NFS byl hooodne opatrnej. Osobne si myslim, ze iSCSI je mnohonasobne vhodnejsi nez NFS a jeho implementace funguje dobre. A z osobni zkusenosti vim, ze cokoliv Oracle nasadi jako zhavou novinku, tak to zacne fungovat az v dalsi verzi (rman, streams ...).

[Ivan]

jj, rman a NFS je dobre leda tak na odzkouseni si disaster recovery scenaru :)

[Ivan]

Pro starsi Oracle muzete pouzit kernel NFS, ale: musite ho namountovat s flagy ktere jsou pro Oracle dulezite. Mezi nimi je i noac, ktery hodne degraduje vykon. Abyste ale mohli pouzit NFS jako uloziste musite musime mit "certifikovany" NFS server. A NFS server implementovany v linux kernelu certifikovany neni. Takze si ten NetApp stejne musite koupit.

[xobot]

ani ja, ale od 31.3. 2010 je oficialna podpora SAPu pre Oracle 11.2 (UNIX/linux).
Ostatne OS do konca roka 2010.

BTW: Oracle predlzilo support 10.2-ky do konca jula/cervence(?) 2011. Viac v note 1339724

[pasmen]

OK dík. Navíc jsem se dočetl (1398634) že 11g je podporována i pro R/3 kernel 6.40. To jsem teda netušil, měl jsem za to že max. 10gR2.

[mrak]

Zajimavy posun neb myslim, ze predchozi verze Oracle nechteli mit s daty ulozenymi na nfs nic spolecneho(aspon co se podporovanych konfiguraci tyce).

No ale vetsinou kdyz mate na Oracle, tak mate i na ty FC legrace okolo.

[nazdarek]

http://www.gluster.com/ (glusterfs)

[snajpa]

Má s tím někdo zkušenost? Hlavně co se děje při výpadku master nodů - jestli se to nerozpadá a funguje to spolehlivě?

[Peppa1]

IMHO malá firma nepotřebuje rozsáhlou FC infrastrukturu. Takže když si koupí plně redundantní sadu SAN + FC switch + 4 FC karty + kabely tak to nebude stát nějaké neuvěřitelné peníze. A vzhledem ke spolehlivosti nepotřebuje prakticky žádnou obsluhu natož pak "více kvalifikovaných lidí".

[koulinek]

Též myslim, firma to nastaví a prostě to funguje :) storage experty si pro pripadne rekonfigurace outsourcuji. Nekdy se fakt divim jak málo jsou nektere firmy ochotny vynalozit na zabezpeceni a ochranu dat, a jak hodne se pak divi kdyz o ty data prijdou.

[Mordae]

Ani ten switch neni treba. Kdyz mate 2 nodovy Oracle cluster, tak si bohate vystacite s porty primo na poli.

[Foo Bar]

A máte představu, kolik stojí 2 FC switche, dva řadiče do pole (+ to pole), 4 FC karty a kabely? Pro malou firmu můžou být neuvěřitelné peníze i půl mega až mega, co tahle sranda bude stát.

[Käyttäjä 11133]

No jenom ty switche budou stát majlant (2x 130k zhruba i za ty hrozné HP StorageWorksy - katalogovka jasně)

[houska]

kdyz uz jsme u matiky a fyziky vite jakou energii dokaze vyvinout Hvezda Smrti na zniceni planety? odpoved zde

rekl bych ze kdysi jsem to videl i na cswu.cz, ale uz jsem to nenasel

[houska]

jejda vedle :D

[..... Izak .....]

No treba na NetAppu to chodi dobre.

No a u NFS se doporucuje nevyuzivat UDP, ale TCP ... pry timeouty dojde k okamzitemu spojeni, napr starsi NetAppy s tim mely problem a se solarisem to pres UDP trvalo az 30sec.

Jinak DB navadi, ze disk pise pomalu, pokud rychle cte, na zapis ma cache a logy ... ty je naopak dobre mit na rychlem disku pro zapis ... a hlavne fyzicky jinem disku a to v polich (cekani na hlavicky)

[xkucf03]

Jen drobnost:

to je cena za použití FC/SAN centralizovaného storage řešení. SAN (Storage Attached Network) infrastruktura nabídne skvělý výkon

Mělo být spíš Storage area network, ne?

[stybla]

Proč centralizové uložiště?

Nemelo by zde byt take "ú"?