W ramach partnerstwa firm Microsoft i Oracle dostępne jest bezpośrednie połączenie między chmurami Azure i OCI. Pozwala ono na łatwe zestawienie wydajnego łącza między infrastrukturą obu chmur z pominięciem zewnętrznych dostawców.

Więcej informacji na ten temat pod https://aka.ms/OracleOnAzure lub www.oracle.com/cloud/oci-azure.html.

Przeprowadzono serię testów porównawczych pozwalających wybrać odpowiednie rozwiązanie przy projektowaniu architektury dla konkretnych wymagań. Celem niniejszego dokumentu jest przedstawienie wyników tych testów oraz wniosków przeprowadzonej analizy wydajności.
Badane były zarówno opóźnienia na poziomie warstwy sieciowej jak i aplikacji mierząc komunikację aplikacji umieszczonej w maszynie wirtualnej do serwisu Autonomicznej Bazy Danych działającego w chmurze OCI.
Testy warstwy sieciowej wykonano uwzględniając wszystkie strefy dostępności w obu chmurach, natomiast w części bazodanowej wykorzystano najwydajniejszą konfigurację pod względem opóźnień sieciowych.

Szczegóły konfiguracyjne:

Infrastrukturę na potrzeby testów utworzono w regionie West Europe / Netherlands Northwest (Amsterdam). Na dzień tworzenia tego dokumentu w regionie tym
jest jedna Availability Domain w chmurze OCI oraz trzy Availability Zones w Microsoft Azure. Z testów wynikło, że połączenie między chmurami realizowane jest między jedną z zon w Azure (w naszym przypadku Availability Zone 3), a jedyną domeną Availability Domain 1 w OCI (numeracja zon w Azure może być inna
w zależności od subskrypcji).

Na potrzeby testów utworzono następujące środowisko w regionie West Europe / Amsterdam:

Po stronie Azure:

  • dedykowana grupa zasobów Azure-OCI
  • sieć VNET 10.20.0.0/16 z jedną podsiecią 10.20.0.0/24
    oraz podsiecią na potrzeby GW
  • trzy maszyny wirtualne azoci-vm3, azoci-vm4, azovi-vm5, każda w innej strefie dostępności (availability zone) z zainstalowanym systemem Oracle Linux 7.7
  • Virtual Network Gateway
  • Express Route
  • Tabelę routingu z właściwymi wpisami pozwalającymi na ruch do sieci OCI
  • odpowiednie wpisy w Network Security Group
  • opcjonalnie włączano opcję FastPath

Po stronie OCI:

  • dedykowany compartment azoci
  • sieć VCN 10.30.0.0/16 z podsieciami 10.30.0.0/24 i 10.30.1.0/24
  • dwie maszyny wirtualne azoci-vm1 i azoci-vm2 z zainstalowanym systemem operacyjnym Oracle Linux 7.7 każda w innej podsieci
  • odpowiednio ustawione Security Lists i Network Security Group
  • Internet Gateway
  • odpowiednie wpisy w Tabeli Routingu
  • Dynamic Routing Gateway
  • Fast Connect

Szczegóły konfiguracji przedstawia poniższy diagram:

Do testów wykorzystano autonomiczną transakcyjną bazę danych Oracle oraz narzędzie Swingbench (Order Entry Benchmark) uruchamiane na serwerze w OCI oraz AZURE.

Konfiguracja bazy autonomicznej:

  • Dedicated Infrastructure: No
  • OCPU Count: 2
  • Storage TB: 1
  • Workload type: Transaction processing
  • Database version: 19c
  • Auto Scaling Enabled: Yes
  • Access Type: Virtual Cloud Network
  • Subnet: azocisubnet10_30_0
  • Privet IP: 10.30.0.3
  • Network Secutity Group: azoci_all

Analiza opóźnień sieciowych

Opóźnienia sieciowe badano podstawowymi narzędziami systemowymi mtr oraz ping. Testy wykonano w kilku konfiguracjach zmieniając parametry połączenia po stronie Azure (FastPath) oraz modyfikując ustawienia sieciowe maszyny wirtualnej również po stronie Azure (Accelerated Networking). Opóźnienia mierzono między maszynami wirtualnymi umieszczonymi w Azure w różnych strefach dostępności a maszyną działającą w OCI.
Po stronie OCI wybrano połączenie o przepustowości 1Gbps, po stronie Azure 50Mbps (modyfikacja na 1Gbps nie wpłynęła na mierzone opóźnienia).
Testy wykonywano w 5cio minutowych sekwencjach.

Z testów wynika:

  • w większości testowanych konfiguracji najniższe opóźnienia były dla maszyny działającej w zonie 3, niemniej jednak przy wyłączonej opcji FastPath opóźnienia do maszyn z każdej z zon są na zbliżonym poziomie (2.5-2.7ms)
  • opóźnienia maleją o ok 50% (do 1ms) przy włączonej opcji FastPath. Dotyczy to jedynie maszyny wirtualnej umieszczonej w zonie 3. Dla pozostałych zon różnice są zaledwie rzędu 10% i opóźnienia nie spadają poniżej 1.9ms niezależnie od włączenia funkcjonalności Accelerated Networking.
  • włączenie funkcjonalności Accelerated Networking jedynie w niewielkim stopniu wpływa na opóźnienia. Zmniejszenie jest rzędu kilku procent. Należy pamiętać, że funkcjonalność ta dostępna jest w maszynach typu  D/DSv2 i  F/Fs  dla co najmniej 2 vCPU oraz  D/Dsv3, E/Esv3,   Fsv2, Lsv2, Ms/Mms and Ms/Mmsv2 dla co najmniej 4 vCPU (https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-cli#limitations-and-constraints)

Wykonano również testy opóźnień wewnątrz sieci w obrębie jednej chmury:

Należy zwrócić uwagę na następujące aspekty:

  • włączenie funkcjonalności Accelerated Networking nie wpływa na opóźnienie
  • opóźnienia pomiędzy maszynami w obrębie jednej zony (lub między zonami 1 i 2) są porównywalne do opóźnień pojawiających się w połączeniu między chmurami w najkorzystniejszej konfiguracji (czyli przy włączonej opcji FastPath)
  • opóźnienia między zonami 1 lub 2 a zoną 3 są większe i porównywalne do opóźnień pojawiających się w połączeniu między chmurami w standardowej konfiguracji (czyli przy wyłączonej opcji FastPath)

Analiza opóźnień w wersji aplikacyjnej

Poniższe wykresy prezentują średnie opóźnienia dla wszystkich rodzajów transakcji mierzone po stronie aplikacji oraz ilość transakcji na sekundę. Na opóźnienie składa się czas przesłania operacji do bazy danych oraz realizację zadania po stronie bazy danych. Wszystkie testy składały się z transakcji typu:

  • Customer Registration
  • Update Customer Details (najktótsze transakcje)
  • Browse Products
  • Order Products (najdłuższe transakcje)
  • Process Orders
  • Browse Orders

Poniżej wyniki testu dla połączenia bezpośredniego – baza autonomiczna + swingbench na serwerze wirtualnym w chmurze Oracle w tej samej sieci.

Poza pikiem zaraz po uruchomieniu testu czasy odpowiedzi są bardzo stabilne ze średnią wartością 8. Średni czas odpowiedzi najkrótszych transakcji (Update Customer Details) wynosił  1,84, a najdłuższych (Order Products) wynosił 16,81.

Poniżej wyniki testu dla połączenia azure -> oci – baza autonomiczna + swingbench na serwerze wirtualnym w chmurze Azure w zonie 3 z połączeniem o przepustowości 50Mbps.

Podobnie jak przy poprzednim wykresie poza początkowym pikiem zaraz po uruchomieniu testu czasy odpowiedzi są bardzo stabilne na poziomie 23 i 22. Średni czas odpowiedzi najkrótszych transakcji (Update Customer Details) wynosił  5,93, a najdłuższych (Order Products) wynosił 49,78.

Poniżej wyniki testu dla połączenia azure -> oci – baza autonomiczna + swingbench na serwerze wirtualnym w chmurze Azure w zonie 3 z połączeniem o przepustowości 1Gbps.

Czasy odpowiedzi są podobne i bardzo stabilne (tak samo jak wykres wyżej). Połączenie różniło się tylko przepustowością łącza co nie miało znacznego wpływu na opóźnienia.
Średni czas odpowiedzi najkrótszych transakcji (Update Customer Details) wynosił  6,28, a najdłuższych (Order Products) wynosił 50,29.

Ostatni test dla połączenia azure -> oci – baza autonomiczna + swingbench na serwerze wirtualnym w chmurze Azure w zonie 3 z włączoną opcją FastPath.

Czasy odpowiedzi są stabilne na poziomie prawie dwukrotnie niższym niż bez włączonej opcji FP – 13.
Średni czas odpowiedzi najkrótszych transakcji (Update Customer Details) wynosił  3,33, a najdłuższych (Order Products) wynosił 27,45.

Poniższa tabela podsumowuje wykonane testy aplikacyjne dla uśrednionych wyników pomiarów:

Najwydajniejsza jest konfiguracja, w której aplikacja umieszczona jest najbliżej bazy danych. Zwiększone czasy opóźnienia pociągają za sobą obniżenie wykonywalnych operacji. Testy prowadzono w takich samych warunkach aplikacji (czyli bez zmian w jej konfiguracji). Modyfikując stopień zrównoleglenia można zwiększyć efektywność przy tym samym poziomie opóźnień.

Odnotujmy następujące obserwacje:

  • połączenie typu interconnect między chmurami Azure i OCI jest stabilne o regulowanej wydajności pozwalając przez to na dostosowanie typu łącza do wymagań aplikacji,
  • zastosowanie połączenia FastPath pozwala znacznie skrócić czas odpowiedzi dla aplikacji wymagających krótkich czasów komunikacji z bazą danych
  • różnica w ilości transakcji na sekundę bezpośrednio wynika z większych opóźnień. Może być to istotne dla bardzo wymagających środowisk aplikacyjnych. Liczba transakcji na sekundę może zostać podniesiona przez zmianę konfiguracji czyli zwiększenie zrównoleglenia po stronie aplikacji (więcej sesij bazodanowych)

Z powyższego wynika, że dzięki funkcjonalności interconnect między chmurami możliwe jest uruchomienie zarówno aplikacji mało wrażliwych na czasy komunikacji z bazą danych jak i bardzo wymagających aplikacji. Pozwala to na realizację różnych kombinacji najlepszych produktów Azure z najlepszymi funkcjonalnościami OCI (jak np. Oracle RAC czy Autonomiczna Baza Danych Oracle)

Nie przeprowadzano tu testów porównawczych dla konfiguracji opartej o VPN bądź zewnętrznego dostawcę łączy między chmurami w tym samym regionie. Z doświadczeń wynika, że czasy opóźnień są w takich konfiguracjach znacznie wyższe co może uniemożliwić komfortową pracę aplikacji.

Data dokumentu: 19.03.2020

Autorzy analizy:

Jacek Drzycimski

Inżynier Systemowy
Dział Oracle, Advatech

Krzysztof Łojek

Inżynier ds. Baz Danych
Dział Oracle, Advatech