Software Defined technológiák használata Oracle adatbázis konszolidációhoz

Átírás

1 Software Defined technológiák használata Oracle adatbázis konszolidációhoz Popovics László Október 2.

2 Technológiai evolúció 2000-es évek eleje A 2000-es években főképp monolit rendszereket használtak a magyarországi cégek. A rendszerek adatainak védelmét tároló szintű védelem látta el, amelyet storage szintű tükrözéssel valósítottak meg. A rendszerek csak hardver szinten skálázhatóak. I/O teljesítmény skálázása csak tengelyek számának növelésével skálázató

3 Technológiai evolúció Oracle adatbáziskezelő egyre több lehetőséget tartalmaz amelyekkel a rendszerek adatainak biztonsága garantálható. Egy szerverbe építhető hardverek teljesítménye exponenciálisan növekszik. Általánosságban elérhetővé válnak a PCIe SSD meghajtók, amellyel a szerverek egyenkénti IOPS teljesítménye összemérhetővé válik a highend központi tárolókkal, ezzel együtt a késleltetés 1-2 nagyságrendet csökken.

4 Technológiai evolúció Az önnálló szerveres megoldások esetében limitációt jelentett a belső bővítőhelyek száma, ezért megjelent az igény a továbbfejlesztésre. Oracle grid infrastructure és iscsi használatával mind a nagy rendelkezésreállás (ASM), mind hatalmas performancia biztosítható. Oracle RAC segítségével a szerverek I/O és adatfeldolgozási teljesítménye skálázható.

5 Építő elemek 1 / 5 Nagy teljesíményű memória node Akár 6TB kapacitás ami DDR3 RAM-ból kerül kiosztásra. Egy ilyen node akár random read/write IOPS-ra képes (8K block mérettel) Infiniband kapcsolat használatával I/O tekintetben 5 GB/s sávszélesség érhető el. Egy egység mérete 4U Több node használatával a sávszélesség lineárisan skálázódik (3 node-os rendszer 1.5m random IOPS elérésére képes és 12.5GB/s sávszélességre, azonban itt már a host a limit amiről a teszt fut. Ideális temp. táblaterekhez.

6 Építő elemek 2 / 5 Nagy teljesítményű SSD node (PCIe SSD) Akár 25.6TB kapacitás node-onként. A PCIe SSD kártyák életciklusa limitált, de a legtöbb vállalat esetében jóval hosszabb még így is, mint amit a hagyományos meghajtók elviselnek. Egy egység 2U magas. Főleg tranzakcionális, alacsony késleltetésű, tárterületekhez használható

7 Építő elemek 3 / 5 Nagy kapacitású SSD node (SAS SSD) Belső SAS SSD diszkből a jelenlegi szerverekbe 25 2,5 os drive építhető, amellyel a belső kapacitás így maximum 60TB meghajtók elviselnek. Az elméleti IOPS szám így 1.875m olvasás esetén 0.375m írás esetén. 2U bővítővel node-onként a diszkek száma 50-re bővíthető, amely 120TB kapacitásnak felel meg.a sávszélességet a chipset fogja itt is limitálni 12.5GB/s-re. Ideális alkalmazása nagy átvitelt igénylő rendszereknél (OLAP)

8 Építő elemek 4 / 5 Nagy kapacitású SAS node (Hagyományos SAS diszk) Az előző node-hoz hasonlóan ez a megoldás is SAS diszkeket alkalmaz, amelyből 1.8TB-os a jelenleg kapható legnagyobb 10k-s fordulatszámú diszk. Ezzel az elérhető kapacitás node-onként 45TB, ami az előző bővítővel 90TB-ra bővíthető. A node I/O teljesítménye IOPS amely jelentősen javítható PCIe SSD alkalmazásával. 2 PCIe kártyával node-onként 12.8TB cache használható. A cache-elt adatok esetében az alábbi adatokkal lehet számolni: 285k Read IOPS(8K), 385k Write IOPS (8k), 5.4/4.200MB/s sávszélesség. Ideális alkalmazása mind OLAP, mind OLTP esetében a ritkábban használt adatok részére.

9 Építő elemek 5 / 5 Nagy kapacitású archív SATA node (7.2K-s SATA diszk) Archiv adatokhoz ki tudunk alakítani, nagy kapacitású SATA node-okat, Ezekhez a node-okhoz használhatunk 4-5U magas kapacitás optimalizált szervereket szervereket, amelyekkel 60-72db 6TB-os drive használható. Ezekkel a konfigurációkkal TB kapacitás érhető el node-onként. (6TB-os diszk esetében), TB 10TBos diszkek használatával. Alkalmas archíváláshoz mind OLTP, OLAP esetében

10 Software defined vs Storage HW Software defined szoftverrel valósítunk meg egy tárolót. A nagy gyártók nem ezt használják? DELL Compellent x86 szerver alapú megoldás EMC VMAX x86 szerver alapú megoldás Oracle Exadata x86 szerver alapú megoldás Netapp FAS8000 x86 szerver alapú megoldás Kérdés? Miért nem vesszük meg a storage-ot szerverként? Így bármikor újraszervezhetjük a rendelkezésre álló hardvereket, ha más bontásban van szükségünk alkalmazás szerverre / tárolóra.

11 Miért Software defined megoldások? Nincs vendor lock-in Rengeteg szállító közül választhatunk Bármikor cserélhetjük a szoftvereket, ha találunk jobbat. Olyan storage-ot építhetünk, amelyre ténylegesen szükségünk van, nem csak a kész konfigurációkból építkezhetünk. - Fontos tudjuk mit akarunk! Ha nincs szükség a tárolóra, vagy más konfiguráció kell, bármikor átépíthetjük más célra.

12 A szoftverek Dönthetünk támogatás vásárlás mellett, vagy használhatunk teljesen szabad disztribúciókat a maguk előnyével, hátrányával: Oracle Enterprise Linux Redhat Suse Linux Vagy teljesen szabad disztribúciók, a maguk szabadságával: CentOS Debian Linux Ubuntu Linux

13 ISCSI initiator Az előbb említett disztribúciók mindegyike tartalmaz iscsi initiatort, de használhatunk egyedi megoldást is. A főbb initiatorok amelyek használhatóak: tgtd scst lio

14 Egy konkrét példa tervezésre Kiindulási rendszer 2 RAC node Intel Xeon X7560 processzorral node-onként 2 socket (8 core per socket) 752 SpecInt rate 2006 RAC-ban (10Gb interconnect a serverek között) 64GB ram / node 40TB adatbázis méret (High-end storage-on : IOPS) Cél : Maximális performancia, azonos licence számmal

15 Egy konkrét példa tervezésre Az új rendszer 4 RAC node DB szerverek 2U server - 2 socket (4 core per socket) E v3 3.5GHz 1888 SpecInt rate GB ram / node 4x56Gb infiniband HBA RHEL v. OEL Linux Storage node-ok: 5 node 2U Storage node-ok (4+1 tartalék) 2 socket (8 core per socket) E cpu 64GB memória 4x6.4TB FusionIO PCIe SSD kártya 2x56Gb infiniband HBA Cél : Maximális performancia, azonos licence számmal

16 Egy konkrét példa tervezésre Az eredmények 2,5x nagyobb teljesítmény Adatbázis sávszélesség a storage fele : 50GB/s (eredeti 4GB/s 4x8Gbit) 50K IOPS 390MB/s Új flash storage : Read IOPS Write IOPS Read Bandwidth 54GB/s Write Bandwidth 42GB/s

17 Egy konkrét példa tervezésre Hálózati konfiguráció különbség az Exadata megoldással szemben Exadata DB node : 2 IB kapcsolat 2 IB kapcsolat failover mode-ban Custom megoldás : 4 IB kapcsolat 2 kapcsolat failover módban a RAC-nak 2 kapcsolat active-active módban a storage fele.

18 Egy konkrét példa tervezésre A sikeres bevezetés kulcsa: Gondos tesztelés Terheléses, és hiba tűrés Üzemeltetés dokumentálása Alkalmazás megismerése, amely az infrastruktúrára költözik, hogy ideális infrastruktúrát tudjunk tervezni. Megfelelő performanciájú tároló rétegek kialakítása Feleslegesen ne használjunk high-end réteget, olyan adatok tárolására, ahol nincs rá szükség.

19 Technológiai evolúció 2015 Az idei évben megjelentek az első NVMe interfésszel rendelkező SSD kártyák, amelyek tekinthetőek a PCIe SSD-k új generációjának. Nagyobb teljesítményt nyújtanak Hosszabb élettartammal rendelkeznek Alacsonyabb késleltetéssel szolgálnak ki ugyan annyi I/O műveletet. Kevesebb host oldali CPU ciklussal szolgálnak ki ugyan annyi I/O műveletet Az NVMe interfészről bővebben:

20 Technológiai evolúció 2015 Az iscsi storage node-okkal akkora teljesítmény érhető el, amely már az adatbázis oldal nem képes kihasználni, érdemes elgondolkodni új lehetőségeken. A Storage node-ok akkora teljesítménnyel rendelkeznek, amelyet már DB oldalról nem igazán lehet kihajtani, a déli híd limitációja miatt. A többlet erőforrás új lehetőségeket kínál komplexebb infrastruktúrákhoz!

21 Software defined backend A jövőben a storage node-ok block device-ai nem fizikai eszközök lesznek, hanem software defined diszkek. Ez általal elérhetőek az alábbi lehetőségek: A diszkek hiba esetén újraépítik magukat. Nagyságrendileg gyorsabb gyógyulás hiba esetén. Hardver csere leállás nélkül, online működő rendszeren. Migráció új hardverre, online működő rendszer mellett. A block device alatti hardverek között egy optimalizáló intelligencia képes módosítani a kiosztásokat, úgy hogy a rendszer kiegyensúlyozottabb legyen. A megoldás már ma is elérhető, de még sok optimalizációra szorul (

22 KÉRDÉSEK?