Prozkoumání velmi rozsáhlých osvědčených postupů migrace databází

Dokončeno

Následující pokyny jsou založené na skutečných zákaznických projektech a učení odvozených z těchto projektů. Pokyny identifikují scénáře, které v minulosti nebyly úspěšné. Příkladem je nepoužívat servery UNIX nebo virtualizované servery jako servery pro export R3load:

• Výkon exportu je často faktorem celkového výpadku. Aktuální hardware je často starší než 4 až 5 let a je pro upgrade příliš nákladný.
• Proto je důležité získat maximální výkon exportu, který je praktický k dosažení.
• Předchozí projekty strávily týdny člověka nebo dokonce měsíce pokusu o ladění výkonu exportu R3load na platformách UNIX nebo virtualizovaných platformách, než se vzdaly a používaly servery Intel R3load.
• Komoditní servery Intel se dvěma sokety jsou levné a poskytují značné zvýšení výkonu, v některých případech větší než menší vylepšení ladění možná na unixových nebo virtualizovaných serverech.
• Zákazníci často mají stávající farmy virtuálních počítačů, ale nejčastěji nepodporují moderní technologie snižování zátěže ani SR-IOV. Často je verze VMware stará, nepatchovaná nebo není nakonfigurovaná pro vysokou propustnost sítě a nízkou latenci. Servery exportu R3load vyžadují vysoký výkon vláken a extrémně vysokou propustnost sítě. Exportní servery R3load můžou běžet po dobu 10 až 15 hodin při téměř 100% využití procesoru a sítě. Toto není typický případ použití většiny farem VMware a většina nasazení VMware nebyla nikdy navržena tak, aby zpracovávala úlohy, jako je například R3load.

Tip

Ne investujte čas do optimalizace výkonu exportu R3load na platformách UNIX nebo virtualizovaných platformách. To bude ztrácet nejen čas, ale bude stát mnohem více než nákup nízkonákladových serverů Intel na začátku projektu. Zákazníci s migrací VLDB proto chtějí zajistit, aby projektový tým měl na začátku projektu k dispozici rychlé moderní exportní servery R3load. Tím se sníží celkové náklady a riziko projektu.

Osvědčené postupy

• Průzkum a inventarizace aktuálního prostředí SAP Identifikujte úrovně balíčku podpory SAP a určete, jestli se pro podporu cílového DBMS vyžaduje opravy. Obecně platí, že kompatibilita operačního systému je určena jádrem SAP a kompatibilita DBMS je určena úrovní SAP_BASIS oprav.
• Vytvořte seznam poznámek SAP OSS, které je potřeba použít ve zdrojovém systému, například aktualizace pro SMIGR_CREATE_DDL. Zvažte upgrade jader SAP ve zdrojových systémech, abyste se vyhnuli velké změně během migrace do Azure (například). Pokud systém používá staré jádro 7.41, aktualizujte na zdrojovém systému nejnovější verzi 7.45, abyste se vyhnuli velké změně během migrace).
• Vývoj a zdokumentování řešení vysoké dostupnosti a zotavení po havárii Dokumentace by měla rozdělit řešení do vrstvy databáze, vrstvy ASCS a aplikačního serveru SAP. Pro samostatná řešení, jako jsou TREX nebo liveCache, se můžou vyžadovat samostatná řešení.
• Vytvořte dokument o velikosti a konfiguraci, který podrobně popisuje typy virtuálních počítačů Azure a konfiguraci úložiště. Kolik disků Premium, kolik datových souborů, jak jsou datové soubory distribuovány mezi disky, využití prostorů úložiště, velikost formátu NTFS = 64 kB. Také zálohování a obnovení dokumentů a konfigurace DBMS, jako jsou nastavení paměti, maximální stupeň paralelismu a traceflags.
• Vytvořte dokument návrhu sítě, včetně virtuální sítě, podsítě, skupiny zabezpečení sítě a konfigurace trasy definované uživatelem.
• Zdokumentujte a implementujte koncept zabezpečení a posílení zabezpečení. Odeberte Internet Explorer, vytvořte kontejner active directory pro účty a servery služby SAP a použijte zásadu brány firewall, která blokuje všechny kromě omezeného počtu požadovaných portů.
• Vytvořte dokument návrhu migrace operačního systému nebo databáze, který podrobně popisuje koncept rozdělení balíčků a tabulek, počet operací R3loads, traceflags SQL Serveru, seřazené/neseřazené nastavení, nastavení Řádku Oracle, nastavení SMIGR_CREATE_DDL, čítače Perfmon (například řádky BCP za sekundu a propustnost BCP kb/s, PROCESOR, paměť), nastavení RSS, nastavení akcelerovaných síťových služeb, konfigurace souboru protokolu, nastavení BPE, konfigurace transparentního šifrování dat.
• Vytvořte graf "Flight Plan" zobrazující průběh exportu a importu R3load v každém testovacím cyklu. To umožňuje týmu migrace ověřit, jestli ladění a změny zlepšují výkon exportu nebo importu R3load. Osa X je počet dokončených balíčků a Osa Y je uplynulý čas. Tento letový plán je také kritický během migrace do produkčního prostředí, aby bylo možné plánovaný průběh porovnat se skutečným průběhem a jakýmkoli problémem zjištěným v rané fázi.
• Vytvořte plán testování výkonnosti. Identifikujte prvních 20 online sestav, dávkových úloh a rozhraní. Zdokumentujte vstupní parametry (například rozsah kalendářních dat, prodejní kancelář, závod, kód společnosti atd.) a moduly runtime v původním zdrojovém systému. Porovnejte modul runtime v Azure. Pokud existují rozdíly v výkonu, spusťte SAT, ST05 a další nástroje SAP k identifikaci neefektivních příkazů.
• Auditujte nasazení a konfiguraci a ujistěte se, že jsou vypršení časového limitu clusteru, jádra, nastavení sítě, velikost formátu NTFS konzistentní s dokumenty návrhu. Nastavte čítače perfmonu na důležitých serverech tak, aby zaznamenávaly základní parametry stavu každých 90 sekund. Ověřte, že jsou servery SAP v samostatném kontejneru AD a že pro něj platí zásady skupiny s konfigurací brány firewall.
• Zkontrolujte, jestli je hlavní konzultant pro migraci operačního systému nebo databáze licencovaný. Požádejte o jméno konzultanta, uživatele a datum certifikace. Otevřete zprávu OSS pro BC-INS-MIG a požádejte SAP, aby potvrdil, že konzultant je aktuální a licencovaný.
• Pokud je to možné, měli celý projektový tým přidružený k projektu migrace VLDB v rámci jednoho fyzického umístění, a ne geograficky rozptýlený napříč několika kontinenty a časovými pásmy.
• Ujistěte se, že je zaveden správný záložní plán a že je součástí celkového plánu.
• Pro servery pro export R3load vyberte modely procesoru Intel s rychlým počtem vláken. Nepoužívejte modely procesoru "Energy Saver", protože mají nižší výkon a nepoužívají 4 soketové servery. Dobrým příkladem je Intel Xeon E5 Platinum 8158.

Osvědčené postupy pro zabránění problémům

• Neodčítejte jednu konzultační organizaci, aby se export a odečítání jiné konzultační organizace k importu. Zdrojový systém je občas mimosourcovaný a spravovaný jednou konzultační organizací nebo partnerem a zákazník chce migrovat do Azure a přepnout na jiného partnera. Vzhledem k úzkému propojení mezi laděním a konfigurací exportu a importu je nepravděpodobné, že přiřazení těchto úloh různým organizacím přinese dobrý výsledek.
• Během migrace neekonomizujte hardwarové prostředky Azure a za provozu. Služba Azure Virtual Machines se účtuje za minutu a dá se snadno zmenšit. Během migrace VLDB použijte nejvýkonnější virtuální počítač, který je k dispozici. Zákazníci úspěšně přešli do provozu na 200–250 % přetěžovaných systémů a pak se stabilizovali při provozu přetěžovaných systémů. Po monitorování využití systému po dobu 4 až 6 týdnů se virtuální počítače s nadbytečnou kapacitou zmenší a sníží tak náklady.