Badanie bardzo dużych najlepszych rozwiązań dotyczących migracji bazy danych

  • 11 min

Poniższe wytyczne są oparte na rzeczywistych projektach klientów i naukach pochodzących z tych projektów. Wytyczne identyfikują scenariusze, które nie powiodły się w przeszłości. Na przykład zaleca się, aby nie używać serwerów system UNIX ani serwerów zwirtualizowanych jako serwery eksportu R3load:

  • Często wydajność eksportu jest czynnikiem wpływającym na ogólny przestój. Często obecny sprzęt jest ponad 4-5 lat i jest zbyt drogi do uaktualnienia.
  • Dlatego ważne jest, aby uzyskać maksymalną wydajność eksportu, która jest praktyczna do osiągnięcia.
  • Poprzednie projekty spędziły wiele tygodni, a nawet miesięcy man-months, próbując dostosować wydajność eksportu R3load na system UNIX lub zwirtualizowanych platformach, przed rezygnacją i użyciem serwerów Intel R3load.
  • Serwery Intel z dwoma gniazdami są niedrogie i zapewniają znaczne wzrosty wydajności, w niektórych przypadkach rzędy wielkości większe niż drobne ulepszenia dostrajania możliwe na serwerach system UNIX lub zwirtualizowanych.
  • Klienci często mają istniejące farmy maszyn wirtualnych, ale najczęściej nie obsługują nowoczesnych technologii odciążania ani technologii SR-IOV. Często wersja programu VMware jest stara, niesprawiona lub nieskonfigurowana pod kątem wysokiej przepływności sieci i małych opóźnień. Serwery eksportu R3load wymagają bardzo szybkiej wydajności wątków i bardzo wysokiej przepływności sieci. Serwery eksportu R3load mogą działać przez 10–15 godzin przy prawie 100% wykorzystania procesora CPU i sieci. Nie jest to typowy przypadek użycia większości farm VMware, a większość wdrożeń VMware nigdy nie została zaprojektowana do obsługi obciążenia, takiego jak R3load.

Napiwek

Nie poświęcaj czasu na optymalizację wydajności eksportu R3load na platformach system UNIX lub zwirtualizowanych. W ten sposób zmarnuje to nie tylko czas, ale będzie kosztować znacznie więcej niż kupowanie tanich serwerów Intel na początku projektu. W związku z tym klienci ds. migracji bazy danych VLDB są proszeni o zapewnienie, że zespół projektu ma szybkie nowoczesne serwery eksportu R3load dostępne na początku projektu. Spowoduje to obniżenie całkowitego kosztu i ryzyka projektu.

Najlepsze rozwiązania

  • Badanie i tworzenie spisu bieżącego środowiska SAP. Zidentyfikuj poziomy pakietu pomocy technicznej SAP i ustal, czy stosowanie poprawek jest wymagane do obsługi docelowej usługi DBMS. Ogólnie rzecz biorąc, zgodność systemu operacyjnego jest określana przez jądro SAP, a zgodność z systemem DBMS jest określana przez poziom poprawek SAP_BASIS.
  • Utwórz listę notatek systemu operacyjnego SAP, które należy zastosować w systemie źródłowym, takich jak aktualizacje SMIGR_CREATE_DDL. Rozważ uaktualnienie jąder SAP w systemach źródłowych, aby uniknąć dużych zmian podczas migracji na platformę Azure (na przykład. Jeśli system korzysta ze starego jądra 7.41, zaktualizuj jądro do najnowszej wersji 7.45 w systemie źródłowym, aby uniknąć dużych zmian podczas migracji.
  • Opracowywanie i dokumentowanie rozwiązania wysokiej dostępności i odzyskiwania po awarii. Dokumentacja powinna podzielić rozwiązanie na warstwę bazy danych, warstwę USŁUGI ASCS i warstwę serwera aplikacji SAP. Oddzielne rozwiązania mogą być wymagane w przypadku rozwiązań autonomicznych, takich jak TREX lub liveCache.
  • Opracuj dokument o określaniu rozmiaru i konfiguracji, który zawiera szczegółowe informacje o typach maszyn wirtualnych platformy Azure i konfiguracji magazynu. Ile dysków w warstwie Premium, ile plików danych, jak są rozproszone pliki danych na dyskach, użycie miejsc do magazynowania, rozmiar formatu NTFS = 64 kb. Ponadto tworzenie kopii zapasowych/przywracanie dokumentów i konfiguracja systemu DBMS, takie jak ustawienia pamięci, maksymalny stopień równoległości i traceflags.
  • Opracuj dokument projektowy sieci, w tym konfigurację sieci wirtualnej, podsieci, sieciowej grupy zabezpieczeń i trasy zdefiniowanej przez użytkownika.
  • Dokumentowanie i implementowanie koncepcji zabezpieczeń i wzmacniania zabezpieczeń. Usuń program Internet Explorer, utwórz kontener usługi Active Directory dla kont usług SAP i serwerów i zastosuj zasady zapory blokujące wszystkie, ale ograniczoną liczbę wymaganych portów.
  • Utwórz dokument projektu migracji systemu operacyjnego/bazy danych zawierający szczegółowe informacje na temat koncepcji podziału pakietu i tabeli, liczby ładunków R3, śladów programu SQL Server, posortowanych/niesortowanych, ustawienia Oracle RowID, SMIGR_CREATE_DDL ustawień, liczników wydajności (takich jak wiersze BCP/s i przepływność BCP kb/s, procesor CPU, pamięć), ustawienia RSS, ustawienia przyspieszonej sieci, konfiguracja pliku dziennika, ustawienia bpE, konfiguracja TDE.
  • Utwórz graf "Plan lotu" przedstawiający postęp eksportu/importu ładunku R3 w każdym cyklu testowym. Dzięki temu zespół ds. migracji może sprawdzić, czy dostrajanie i zmiany poprawią wydajność eksportu lub importu R3load. Oś X to liczba ukończonych pakietów, a oś Y to czas, który upłynął. Ten plan lotu ma również krytyczne znaczenie podczas migracji produkcyjnej, dzięki czemu planowane postępy można porównać z rzeczywistym postępem i wszelkimi zidentyfikowanym wcześniej problemami.
  • Utwórz plan testowania wydajnościowego. Zidentyfikuj 20 najważniejszych raportów online, zadań wsadowych i interfejsów. Dokumentowanie parametrów wejściowych (takich jak zakres dat, biuro sprzedaży, zakład, kod firmy itp.) i środowiska uruchomieniowe w oryginalnym systemie źródłowym. Porównanie ze środowiskiem uruchomieniowym na platformie Azure. Jeśli występują różnice w wydajności, uruchom polecenie SAT, ST05 i inne narzędzia SAP, aby zidentyfikować nieefektywne instrukcje.
  • Przeprowadź inspekcję wdrożenia i konfiguracji oraz upewnij się, że limity czasu klastra, jądra, ustawienia sieciowe, rozmiar formatu NTFS są zgodne z dokumentami projektowymi. Ustaw liczniki wydajności na ważnych serwerach, aby rejestrować podstawowe parametry kondycji co 90 sekund. Sprawdź, czy serwery SAP znajdują się w oddzielnym kontenerze usługi AD i czy kontener ma do niego zastosowane zasady grupy z konfiguracją zapory.
  • Sprawdź, czy główny konsultant ds. migracji systemu operacyjnego/bazy danych ma licencję! Zażądaj nazwy konsultanta, użytkownika s-user i daty certyfikacji. Otwórz komunikat systemu operacyjnego na BC-INS-MIG i poproś firmę SAP o potwierdzenie, że konsultant jest aktualny i licencjonowany.
  • Jeśli to możliwe, cały zespół projektu skojarzony z projektem migracji bazy danych VLDB w jednej lokalizacji fizycznej, a nie geograficznie rozproszony na kilku kontynentach i strefach czasowych.
  • Upewnij się, że istnieje odpowiedni plan rezerwowy i że jest on częścią ogólnego harmonogramu.
  • Wybierz modele procesora Intel z liczbą wątków dla serwerów eksportu R3load. Nie używaj modeli procesora CPU "Oszczędzanie energii", ponieważ mają niższą wydajność i nie używają serwerów 4-gniazdowych. Procesor Intel Xeon E5 Platinum 8158 jest dobrym przykładem.

Najlepsze rozwiązania dotyczące unikania problemów

  • Nie odjmij jednej organizacji konsultingowej, aby wykonać eksport i podwykonać inną organizację konsultingową w celu przeprowadzenia importu. Czasami system źródłowy jest zlecany i zarządzany przez jedną organizację konsultingową lub partnera, a klient chce przeprowadzić migrację na platformę Azure i przełączyć się do innego partnera. Ze względu na ścisłe sprzężenie między dostrajaniem eksportu i importowaniem i konfiguracją jest mało prawdopodobne, że przypisanie tych zadań do różnych organizacji przyniesie dobry wynik.
  • Podczas migracji nie ekspansuj zasobów sprzętowych platformy Azure i nie ekspansuj na żywo. Opłaty za maszyny wirtualne platformy Azure są naliczane za minutę i można je łatwo zmniejszyć. Podczas migracji bazy danych VLDB użyj najbardziej wydajnej dostępnej maszyny wirtualnej. Klienci pomyślnie mieszkali w 200-250% ponadwymiarowych systemach, a następnie ustabilizowali się podczas uruchamiania ponadwymiarowych systemów. Po monitorowaniu wykorzystania systemu przez 4–6 tygodni maszyny wirtualne z nadmiarową pojemnością są zmniejszane lub zamykane w celu obniżenia kosztów.