SAN versus NAS und die Oracle Datenbank. Datenbanken sind unsere Welt

Transkript

1 SAN versus NAS und die Oracle Datenbank

2 Themenübersicht Grundlagen Was ist SAN? Was ist NAS? SAN versus NAS Real Live Performance Vergleich Mehrere Bespiele

3 SAN versus NAS Grundlagen Was ist SAN? Was ist NAS? Was ist iscsi? Oracle Datenbank I/O Anforderungen Review Protokolle und Overheads SAN versus NAS

4 Was ist SAN? Ist ein BLOCK Protokoll Storage stellt (shared) LUNs eine Ansammlung von Blocks zur Verfügung LUNs werden als DEVICE im Operatingsystem eingebunden Lediglich read/write von individuellen Blöcken wird durchgeführt Platz der LUN ist oft sofort verbraucht Thin Provisioning möglich, hilft aber nur bedingt (Beispiel: ASM Formatierung, )

5 SAN Konfigurationsschritte Kompatibilitätsmatrix evaluieren, HBA Firmware und Treiber vorhandener Systeme aktualisieren Storage aufbauen FC (SAN) Switches aufbauen SAN/HBA Adapter in Server einbauen Alles korrekt verkabeln LUNs im Storagesystem definieren LUNs den Servern zuordnen SAN Zonen im Switch konfigurieren LUN/Device im OS einbinden (Logical Volume Manager), Partitionieren, Filesystem erzeugen, mounten

6 Was ist NAS? NAS ist ein FILE Protokoll Storage stellt ein (shared) Filesystem zur Verfügung Das Operating System greift auf Files zu Nur der von den Files belegte Platz ist verbraucht

7 NAS Konfiguration Storage aufbauen Netzwerk Switch aufbauen Server/Storage verkabeln Volumes in der Storage definieren Volumes für die Server freigeben Volumes als NFS Filesystem mounten

8 Was ist iscsi? Aus Sicht des Zugriffes iscsi spricht eine LUN auf der Storage an und bindet diese als Devices im OS ein somit wie SAN Aus Sicht der Verkabelung iscsi nutzt TCP/IP und somit das Netzwerk um auf die Storage zuzugreifen aus dieser Sicht NAS iscsi verwendet man, wenn man zwingend ein DEVICE benötigt aber eine NAS Storage nutzen möchte.

9 Zur Erinnerung Welchen I/O macht Oracle eigentlich? DB_BOCK_SIZE (meist 8k) LESEN und SCHREIBEN Full Table/Index Scan (sollte 1 MB sein) LESEN REDO 512 Bytes bis maximal 64 MB SCHREIBEN BULK I/O (meist >= 1 MB) ARCHIVER, LOADER, LESEN und SCHREIBEN Performancerelevant REDO schreiben durch LGWR LESEN sowohl DB_BLOCK_SIZE als auch FTS Unter dem Strich ist das wichtigste: Möglichst geringe Latenz mit möglichst geringem CPU Overhead

10 Kleiner Ausflug wie man Latenz reduziert I/O Arten: sync versus async(im SAN) Datenbank Server SGA DBWR Filesystem Cache acknowledge Synchroner I/O Der DBWR schreibt einen Block und muss auf das acknowledge warten. Dann erst kommt der nächste Block dran. Asynchroner I/O Der DBWR schreibt ALLE Blöcke sofort, hintereinander und wartet dann auf die acknowledges. SAN Fabric SAN Storage

11 I/O Arten: normal versus direct(im SAN) SAN Fabric Datenbank Server SGA Filesystem Cache DBWR direct normal Der Filesystem Cache ist dazwischen geschalten. direct Der Prozess umgeht das Filesystem Cache. Oracle SETALL Bedeutet DIRECT und ASYNC SAN Storage

12 Filesystem Cache versus Oracle Buffer Cache Findet ein Prozess einen Block im Oracle Buffer Cache, kann dieser sofort genutzt werden Zugriffzeit im Nanosekundenbereich (einige CPU Takte) Findet der Prozess den Block nicht, wird ein I/O generiert der vom Filesystem Cache bearbeitet wird. Ist der Block im FS Cache wird dieser in den Buffer Cache kopiert Zugriff im Microsekundenbereich (einige 100 bis einige 1000 CPU Takte). Overhead: zusätzliche Applikation Context Switches auf der CPU.

13 Aktuelle Server wo vergeht die Zeit bei einem Netzwerkzugriff (Quelle: Cisco) Applikation Betriebssystem Treiber, TeamingSW NW Karte

14 Warum denken viele, dass SAN schneller ist? 4 bzw 8 > 1

15 Storage Anbindung Jahr Anbindung MB/Sec Max Devices Max Entfernung Bemerkung 1986SCSI Meter 1994SCSI Meter 1996SCSI Meter 1997Ultra-2 SCSI Meter 19971GB FC/SAN Kilometer 19981GB Ethernet/NFS 100 kein Limit Kilometer 20012GB FC/SAN Kilometer GB Ethernet/NFS 1000 kein Limit Kilometer keiner kauft es, weil viel zu teuer!! 20054GB FC/SAN Kilometer 20088GB FC/SAN Kilometer GB Ethernet/NFS 1000 kein Limit Kilometer wird preislich interessant GB FC/SAN Kilometer aktuell noch sehr teuer 40/100 GB 40000/ kein Limit Kilometer aktuell noch sehr teuer

16 Wer ist somit schneller? 8 < < 40

17 Wer ist somit schneller? Aktueller Stand der Technik SAN: 16GBit seit Mitte 2011 gibt es erste Produkte NAS: 40GBit / 100 GBit seit 17 Juni 2010 standardisiert erste Produkte (Cisco) seit 2008 verfügbar seit 2011 gibt es erste Produkte

18 Was sagen SAN Anhänger zu NAS Gerade große Server nutzen im SAN mehrere Pfade zb: 2 oder 4 mal 8GBit Bei NAS muss man Bonding/Truncing konfigurieren Das kostet ja viel CPU Performance! und nicht immer sind alle Pfade genutzt! Jumbo Frames Sind unsicher SAN nutzt Direct Memory Access, NAS benötigt Interrupts

19 Mehrere Pfade Was sagen SAN Anhänger zu NAS Die Antworten Ja, aber oft sind im SAN nicht alle Pfade aktiv! Oracle dnfs unterstützt bis zu vier unabhängige Pfade in die Storage Ja, Bonding/Truncing bedeutet einen CPU Overhead Richtig, aber auch hier gilt: Oracle dnfs unterstützt bis zu vier unabhängige Pfade man braucht Bonding/Truncing nicht zwingend Jumbo Frames Sind seit vielen Jahren eine erprobte Technologie. Ab 10GBit bis zu 64k Jumbo Frames standardisiert. SAN nutzt Direct Memory Access, NAS benötigt Interrupts Und trotzdem ist der Systemoverhead bei Oracle dnfs deutlich geringer

20 Warum ist SAN bei Tests oft trotzdem schneller? SAN hat eine fixe vorgegebene Infrastruktur STORAGE SAN Switch (Fabric) Server Kurze Wege, geringe Latenz NAS wird oft einfach angebunden STORAGE Backbone Switch Router/Firewall Stockwerk Switch 19 RACK Switch Server Zusätzlich muss die Bandbreite mit anderen TCP/IP Anwendungen geteilt werden Lösung dazu NFS benötigt eine SAN ähnliche Infrastruktur Weg vom Klassischen Netzwerkdesign hin zur Spine-Leaf Architektur Spine Leaf

21 Storage braucht ein Storage Netzwerk Egal welche Storage Sie nutzen, sorgen Sie für ein eigenes Storage Netzwerk! Nutzen Sie dieses Netzwerk nicht als Backup LAN! Nutzen Sie diese Netzwerk nicht als End-User LAN! Sorgen Sie dafür, dass die Switches nicht durch Last auf anderen Ports überlastet sind. Idealerweise getrennte VLANs für verschiedene Nutzungsarten. Damit gibt es auch Kontrolle über Traffic Weiterleitungen wird!

22 Wo geht die Reise im Netzwerk Infrastrukturbereich hin? UNIFIED Netzwerkkomponenten SAN und TCP/IP in einer Lösung UNIFIED Ports man kann sich aussuchen, was wann benötigt SAN wird über TCP/IP geleitet (FCoE) Jumbo Frame Müssen von allen Komponenten unterstützt werden (Storage, Netzwerk, Server) Alle aktuellen Operating Systeme unterstützen Jumbo Frames seit vielen Jahren Auch VMware unterstützt diese seit mehreren Versionen Wird auch für FCoE genutzt, wenn es auf Performance ankommt.

23 Protokolle im Vergleich SAN Start of frame FC header Data CRC End of frame 4 bytes 24 bytes 2112 bytes 4 bytes 4 bytes

24 Ethernet Header Ethernet checksum IP Header TCP Header TCP Checksum TCP SACK TCP Timestamp NFS Header Data Protokolle im Vergleich NAS (mit Jumbo Frame) 22 bytes 4 bytes 20 bytes 18 bytes 2 bytes 6 bytes 6 bytes 148 bytes 8800 bytes

25 Ethernet Header Protokolle im Vergleich iscsi(mit Jumbo Frame) Ethernet checksum IP Header TCP Header TCP Checksum TCP SACK TCP Timestamp iscsi Header Data 22 bytes 4 bytes 20 bytes 18 bytes 2 bytes 6 bytes 6 bytes 48 bytes 8764 bytes

26 Protokolle im Vergleich: Übertragen eines 8k Oracle Blocks FCP NFS iscsi Datagrams Data Overhead Bit Efficiency 98.27% 97.32% 98.49%

27 Somit könnte man sagen aktuell SAN NAS 8 10

28 Aber in naher Zukunft SAN < NAS 16 < 40

29 Oracle zeigt mit dnfs, dass im TCP/IP die Zukunft vermutet wird Oracle dnfs gibt es seit Oracle 11g (auch für Windows) Dadurch, dass jeder mit der Instanz verbundene Oracle Prozess direkt eine NFS Verbindung unterhält, gibt es keine Queues oder anderen Engpässe. Oracle unterstützt ab 12c auch NFS V4 und NFS4.1 Oracle arbeitet intern an der pnfs Unterstützung pnfs sucht sich den optimalen Zugriff auf die Daten, wenn mehrere Wege möglich sind

30 Unterschied zwischen NFS und dnfs Datenbank Server SGA DBWR NFS Client Normales NFS dnfs Storage LAN NAS Storage FS Cache Bei NFS liegt das Filesystem (und das Cache) im Storage. Normales NFS Der I/O Request wird über einen NFS Client abgewickelt dnfs Der I/O erfolgt über einen Oracle internen NFS Client direkt ohne Context Switches

31 Real Live Performance vergleiche Performanceunterschied NFS und dnfs Auswirkung von RMAN Backups mit und ohne dnfs Performancegewinn durch dnfs bei SALK

32 Performanceunterschied mit und ohne dnfs 10 GbitNFS, NetApp mit Flash Cache, kleine DB IO Calibrate ohne dnfs IOPS: Latency: praktisch 0 MB/Sec: 1046 IO Calibrate mit dnfs IOPS: Latency: 0 MB/Sec: 1059 Bei 8k Blocksize sind IOPS das Limit bei 10GBit Netzwerk!

33 Operatingsystem Auslastung bei dnfs Backup SAP DB mit 2TB mit RMAN 8 Channel Ohne dnfs Laufzeit: 93 Minuten Durchsatz: ca. 300MB/sec IO Waits DB Server: 60-70% CPU %idle: ca.25% Mit dnfs Laufzeit: 48 Minuten Durchsatz: ca. 600MB/sec IO Waits DB Server: 0% CPU %idle: ca.80% Anwender haben sich über die schlechte Performance beschwert! Anwender haben das Backup nicht wahrgenommen!

34 Beispiel dnfs Implementierung bei SALK System IOPS SAN IOPS NAS Bemerkung INF1 - ca Kleine Test Datenbank, die komplett in den Cache der NetApp passt das Limit ist, was die NetApp an Datenpaketen ausliefern kann. PRE Die Umstellung auf dnfs hat den Durchsatz verdoppelt. SST PACSP Nur auf SAN, Umstellung geplant TST SAN: vom , NAS: trotzdem die Last in dem Zeitraum gestiegen ist!

35 Ergebnisse der Umstellung Durchsatz und Latenzen Bei SALK SAN / FC MAX IOPS = MAX MBPS = 332 dnfs MAX IOPS = MAX MBPS = 382 Bei den IOPS ein Faktor von ca. 1.8 schneller Latenz bei DBF I/Os Großteils 8 und 16ms Latenz bei DBF I/Os Großteils bei 4 und 8ms

36 Zusammenfassung Ist SAN versus NAS ein Glaubenskrieg? Ja, definitiv Wer hat zumindest aus heutiger Sicht die besseren Karten? Vermutlich NAS und iscsi Weniger administrative Probleme Flexibler, belegt nur den Platz, der wirklich benötigt wird Schneller (40GBit / 100GBit) Bei Oracle mit dnfs wird auch die CPU entlastet und der Durchsatz steigt In Zukunft werden immer mehr Technologien auf TCP/IP Basis kommen, die das Leben einfacher machen. Im reinen SAN Umfeld gibt es dagegen kaum Innovationen.

37 Q & A