Wybieranie odpowiedniej konfiguracji środowiska Integration Runtime dla danego scenariusza

Środowisko Integration Runtime jest ważną częścią infrastruktury rozwiązania do integracji danych dostarczonego przez usługę Azure Data Factory. Wymaga to pełnego rozważenia, jak dostosować się do istniejącej struktury sieci i źródła danych na początku projektowania rozwiązania, a także rozważyć wydajność, bezpieczeństwo i koszty.

Porównanie różnych typów środowisk Integration Runtime

W usłudze Azure Data Factory mamy trzy rodzaje środowisk Integration Runtime: środowisko Azure Integration Runtime, własne środowisko Integration Runtime i środowisko Azure SSIS Integration Runtime. W przypadku środowiska Azure Integration Runtime można również włączyć zarządzaną sieć wirtualną, co sprawia, że jej architektura różni się od globalnego środowiska Azure Integration Runtime.

W tej tabeli wymieniono różnice w niektórych aspektach wszystkich środowisk Integration Runtime. Możesz wybrać odpowiedni zgodnie z rzeczywistymi potrzebami. W przypadku środowiska Azure-SSIS Integration Runtime możesz dowiedzieć się więcej w artykule Tworzenie środowiska Azure-SSIS Integration Runtime.

Funkcja	Azure Integration Runtime	Środowisko Azure Integration Runtime z zarządzaną siecią wirtualną	Infrastruktura Integration Runtime (Self-hosted)
Zarządzane obliczenia	Y	Y	N
Skalowanie automatyczne	Y	Y*	N
Przepływ danych	Y	Y	N
Dostęp do danych lokalnych	N	Y**	Y
Private Link/Prywatny punkt końcowy	N	Y***	Y
Niestandardowy składnik/sterownik	N	N	Y

* Po włączeniu czasu wygaśnięcia (TTL) rozmiar obliczeniowy środowiska Integration Runtime jest zarezerwowany zgodnie z konfiguracją i nie może być automatycznie skalowany.

** Środowiska lokalne muszą być połączone z platformą Azure za pośrednictwem usługi Express Route lub sieci VPN. Składniki niestandardowe i sterowniki nie są obsługiwane.

Prywatne punkty końcowe są zarządzane przez usługę Azure Data Factory.

Ważne jest, aby wybrać odpowiedni typ środowiska Integration Runtime. Nie tylko musi być odpowiednia dla istniejącej architektury i wymagań dotyczących integracji danych, ale także należy wziąć pod uwagę sposób dalszego zaspokajania rosnących potrzeb biznesowych i przyszłego wzrostu obciążenia. Ale nie ma jednego uniwersalnego podejścia. Następujące kwestie mogą pomóc w nawigowaniu po decyzji:

1. Jakie są lokalizacje środowiska Integration Runtime i magazynu danych?
   Lokalizacja środowiska Integration Runtime definiuje lokalizację obliczeń zaplecza oraz lokalizację przenoszenia danych, wysyłania działań i przekształcania danych. Aby uzyskać lepszą wydajność i wydajność transmisji, środowisko Integration Runtime powinno być bliżej źródła danych lub ujścia.

   • Środowisko Azure Integration Runtime automatycznie wykrywa najbardziej odpowiednią lokalizację na podstawie niektórych reguł (nazywanych również autoresolve). Zobacz szczegóły tutaj: Lokalizacja środowiska Azure IR.
   • Środowisko Azure Integration Runtime z zarządzaną siecią wirtualną ma ten sam region co fabryka danych. Nie można go automatycznie rozpoznać, takiego jak środowisko Azure Integration Runtime.
   • Własne środowisko Integration Runtime znajduje się w regionie maszyn lokalnych lub maszyn wirtualnych platformy Azure.

2. Czy magazyn danych jest publicznie dostępny?
   Jeśli magazyn danych jest publicznie dostępny, różnica między różnymi typami środowisk Integration Runtime nie jest duża. Jeśli magazyn znajduje się za zaporą lub w sieci prywatnej, takiej jak lokalna lub wirtualna, lepszym wyborem są środowisko Azure Integration Runtime z zarządzaną siecią wirtualną lub własnym środowiskiem Integration Runtime.

   • W przypadku używania środowiska Azure Integration Runtime z zarządzaną siecią wirtualną w celu uzyskania dostępu do magazynu danych za zaporą lub w sieci prywatnej jest wymagana dodatkowa konfiguracja, taka jak usługa Private Link i moduł równoważenia obciążenia. W tym samouczku możesz zapoznać się z artykułem Access on-premises SQL Server from Data Factory Managed VNet using Private Endpoint (Dostęp do lokalnego programu SQL Server z zarządzanej sieci wirtualnej usługi Data Factory przy użyciu prywatnego punktu końcowego ) jako przykładu. Jeśli magazyn danych znajduje się w środowisku lokalnym, środowisko lokalne musi być połączone z platformą Azure za pośrednictwem usługi Express Route lub sieci VPN typu lokacja-lokacja.
   • Własne środowisko Integration Runtime jest bardziej elastyczne i nie wymaga dodatkowych ustawień, usługi Express Route ani sieci VPN. Ale musisz zapewnić i obsługiwać maszynę samodzielnie.
   • Możesz również dodać publiczne adresy IP środowiska Azure Integration Runtime do listy dozwolonych zapory i zezwolić na dostęp do magazynu danych, ale nie jest to pożądane rozwiązanie w wysoce bezpiecznych środowiskach produkcyjnych.

3. Jakiego poziomu zabezpieczeń wymagasz podczas przesyłania danych?
   Jeśli musisz przetworzyć wysoce poufne dane, chcesz bronić się przed, na przykład atakami typu man-in-the-middle podczas przesyłania danych. Następnie możesz użyć prywatnego punktu końcowego i usługi Private Link, aby zapewnić bezpieczeństwo danych.

   • Zarządzane prywatne punkty końcowe można tworzyć w magazynach danych podczas korzystania ze środowiska Azure Integration Runtime z zarządzaną siecią wirtualną. Prywatne punkty końcowe są obsługiwane przez usługę Azure Data Factory w zarządzanej sieci wirtualnej.
   • Możesz również utworzyć prywatne punkty końcowe w sieci wirtualnej, a własne środowisko Integration Runtime może ich używać do uzyskiwania dostępu do magazynów danych.
   • Środowisko Azure Integration Runtime nie obsługuje prywatnego punktu końcowego i usługi Private Link.

4. Jaki poziom konserwacji można zapewnić?
   Utrzymywanie infrastruktury, serwerów i sprzętu jest jednym z ważnych zadań działu IT przedsiębiorstwa. Zwykle zajmuje dużo czasu i wysiłku.

   • Nie musisz martwić się o konserwację, taką jak aktualizacja, poprawka i wersja środowiska Azure Integration Runtime oraz środowisko Azure Integration Runtime z zarządzaną siecią wirtualną. Usługa Azure Data Factory zajmuje się wszystkimi pracami konserwacyjnymi.
   • Ponieważ własne środowisko Integration Runtime jest zainstalowane na maszynach klienckich, konserwacja musi być zajęta przez użytkowników końcowych. Można jednak włączyć automatyczną aktualizację, aby automatycznie pobrać najnowszą wersję własnego środowiska Integration Runtime za każdym razem, gdy jest dostępna aktualizacja. Aby dowiedzieć się, jak włączyć automatyczną aktualizację i zarządzać kontrolą wersji własnego środowiska Integration Runtime, zapoznaj się z artykułem Self-hosted Integration Runtime autoupdate and expire notification (Automatyczne aktualizowanie i wygasanie). Udostępniamy również narzędzie diagnostyczne dla własnego środowiska Integration Runtime do sprawdzania kondycji niektórych typowych problemów. Aby dowiedzieć się więcej o narzędziu diagnostycznym, zapoznaj się z artykułem Self-hosted Integration Runtime diagnostic tool (Narzędzie diagnostyczne własnego środowiska Integration Runtime). Ponadto zalecamy używanie usług Azure Monitor i Azure Log Analytics w szczególności do zbierania tych danych i włączania pojedynczego okienka monitorowania szkła dla własnych środowisk Integration Runtime. Dowiedz się więcej na temat konfigurowania tej funkcji w artykule Konfigurowanie własnego środowiska Integration Runtime dla kolekcji usługi Log Analytics, aby uzyskać instrukcje.

5. Jakie są wymagania dotyczące współbieżności?
   Podczas przetwarzania danych na dużą skalę, takich jak migracja danych na dużą skalę, mamy nadzieję zwiększyć wydajność i szybkość przetwarzania, jak to możliwe. Współbieżność jest często głównym wymaganiem dotyczącym integracji danych.

   • Środowisko Azure Integration Runtime ma najwyższą obsługę współbieżności wśród wszystkich typów środowiska Integration Runtime. Jednostka integracji danych (DIU) to jednostka możliwości uruchamiania w usłudze Azure Data Factory. Możesz wybrać żądaną liczbę jednostek DIU, na przykład działanie Kopiuj. W zakresie diu można uruchomić wiele działań w tym samym czasie. W przypadku różnych grup regionów będziemy mieć różne górne ograniczenia. Dowiedz się więcej o tych limitach w artykule Limity usługi Data Factory.
   • Środowisko Azure Integration Runtime z zarządzaną siecią wirtualną ma podobny mechanizm do środowiska Azure Integration Runtime, ale ze względu na pewne ograniczenia architektury współbieżność, którą może obsługiwać, jest mniejsza niż środowisko Azure Integration Runtime.
   • Współbieżne działania uruchamiane przez własne środowisko Integration Runtime zależą od rozmiaru maszyny i rozmiaru klastra. Możesz wybrać większą maszynę lub użyć większej liczby węzłów integracji hostowanych samodzielnie w klastrze, jeśli potrzebujesz większej współbieżności.

6. Czy potrzebujesz określonych funkcji?
   Istnieją pewne różnice funkcjonalne między typami środowisk Integration Runtime.

   • Przepływ danych jest obsługiwany przez środowisko Azure Integration Runtime i środowisko Azure Integration Runtime z zarządzaną siecią wirtualną. Nie można jednak uruchomić przepływu danych przy użyciu własnego środowiska Integration Runtime.
   • Jeśli musisz zainstalować składniki niestandardowe, takie jak sterowniki ODBC, JVM lub certyfikat programu SQL Server, własne środowisko Integration Runtime jest jedyną opcją. Składniki niestandardowe nie są obsługiwane przez środowisko Azure Integration Runtime ani środowisko Azure Integration Runtime z zarządzaną siecią wirtualną.

Architektura środowiska Integration Runtime

Na podstawie cech każdego środowiska Integration Runtime różne architektury są wymagane, aby spełnić potrzeby biznesowe integracji danych. Poniżej przedstawiono niektóre typowe architektury, których można użyć jako odwołania.

Azure Integration Runtime

Środowisko Azure Integration Runtime to w pełni zarządzane, automatycznie skalowane zasoby obliczeniowe, których można użyć do przenoszenia danych ze źródeł danych platformy Azure lub spoza platformy Azure.

1. Ruch ze środowiska Azure Integration Runtime do magazynów danych odbywa się za pośrednictwem sieci publicznej.
2. Udostępniamy szereg statycznych publicznych adresów IP dla środowiska Azure Integration Runtime, a te adresy IP można dodać do listy dozwolonych docelowej zapory magazynu danych. Aby dowiedzieć się więcej o sposobie uzyskiwania publicznych adresów IP środowiska Azure Integration Runtime, zapoznaj się z artykułem Adresy IP środowiska Azure Integration Runtime.
3. Środowisko Azure Integration Runtime może być autoresolved zgodnie z regionem źródła danych i ujścia danych. Możesz też wybrać określony region. Zalecamy wybranie regionu znajdującego się najbliżej źródła danych lub ujścia, co może zapewnić lepszą wydajność wykonywania. Dowiedz się więcej o zagadnieniach dotyczących wydajności w artykule Rozwiązywanie problemów z działaniem kopiowania w środowisku Azure IR.

Środowisko Azure Integration Runtime z zarządzaną siecią wirtualną

W przypadku korzystania ze środowiska Azure Integration Runtime z zarządzaną siecią wirtualną należy używać zarządzanych prywatnych punktów końcowych do łączenia źródeł danych w celu zapewnienia bezpieczeństwa danych podczas transmisji. W przypadku niektórych dodatkowych ustawień, takich jak usługa Private Link i moduł równoważenia obciążenia, zarządzane prywatne punkty końcowe mogą być również używane do uzyskiwania dostępu do lokalnych źródeł danych.

1. Zarządzany prywatny punkt końcowy nie może być ponownie używany w różnych środowiskach. Należy utworzyć zestaw zarządzanych prywatnych punktów końcowych dla każdego środowiska. W przypadku wszystkich źródeł danych obsługiwanych przez zarządzane prywatne punkty końcowe zapoznaj się z artykułem Obsługiwane źródła danych i usługi.
2. Możesz również użyć zarządzanych prywatnych punktów końcowych dla połączeń z zewnętrznymi zasobami obliczeniowymi, które mają być orkiestracyjne, takie jak azure Databricks i Azure Functions. Aby wyświetlić pełną listę obsługiwanych zasobów obliczeniowych zewnętrznych, zapoznaj się z artykułem Obsługiwane źródła danych i usługi.
3. Zarządzana sieć wirtualna jest zarządzana przez usługę Azure Data Factory. Komunikacja równorzędna sieci wirtualnych nie jest obsługiwana między zarządzaną siecią wirtualną a siecią wirtualną klienta.
4. Klienci nie mogą bezpośrednio zmieniać konfiguracji, takich jak reguła sieciowej grupy zabezpieczeń w zarządzanej sieci wirtualnej.
5. Jeśli jakakolwiek właściwość zarządzanego prywatnego punktu końcowego różni się między środowiskami, możesz ją zastąpić, parametryzując daną właściwość i podając odpowiednią wartość podczas wdrażania. Zobacz szczegółowe informacje w artykule Najlepsze rozwiązania dotyczące ciągłej integracji/ciągłego wdrażania.

Infrastruktura Integration Runtime (Self-hosted)

Aby zapobiec ingerowaniu między danymi w różne środowiska i zapewnić bezpieczeństwo środowiska produkcyjnego, musimy utworzyć odpowiednie własne środowisko Integration Runtime dla każdego środowiska. Zapewnia to wystarczającą izolację między różnymi środowiskami.

Ponieważ własne środowisko Integration Runtime działa na maszynie zarządzanej przez klienta, aby zmniejszyć koszty, konserwację i uaktualnianie, jak najwięcej, możemy użyć udostępnionych funkcji własnego środowiska Integration Runtime dla różnych projektów w tym samym środowisku. Aby uzyskać szczegółowe informacje na temat udostępniania własnego środowiska Integration Runtime, zapoznaj się z artykułem Tworzenie udostępnionego własnego środowiska Integration Runtime w usłudze Azure Data Factory. W tym samym czasie, aby dane były bezpieczniejsze podczas transmisji, możemy użyć łącza prywatnego, aby połączyć źródła danych i magazyn kluczy, a także połączyć komunikację między własnym środowiskiem Integration Runtime i usługą Azure Data Factory.

1. Usługa Express Route nie jest obowiązkowa. Bez usługi Express Route dane nie docierają do ujścia za pośrednictwem sieci prywatnych, takich jak sieć wirtualna lub łącze prywatne, ale za pośrednictwem sieci publicznej.
2. Jeśli sieć lokalna jest połączona z siecią wirtualną platformy Azure za pośrednictwem usługi Express Route lub sieci VPN, na maszynach wirtualnych w sieci wirtualnej koncentratora można zainstalować własne środowisko Integration Runtime.
3. Architektura sieci wirtualnej piasty i szprych może być używana nie tylko dla różnych projektów, ale także dla różnych środowisk (Prod, QA i Dev).
4. Własne środowisko Integration Runtime może być współużytkowane z wieloma fabrykami danych. Podstawowa fabryka danych odwołuje się do niego jako udostępnione własne środowisko Integration Runtime, a inne nazywają je połączonym własnym środowiskiem Integration Runtime. Fizyczne własne środowisko Integration Runtime może mieć wiele węzłów w klastrze. Komunikacja odbywa się tylko między podstawowym własnym środowiskiem Integration Runtime i węzłem podstawowym, a praca jest dystrybuowana do węzłów pomocniczych z węzła podstawowego.
5. Poświadczenia lokalnych magazynów danych można przechowywać na komputerze lokalnym lub w usłudze Azure Key Vault. Usługa Azure Key Vault jest zdecydowanie zalecana.
6. Komunikacja między własnym środowiskiem Integration Runtime i fabryką danych może przechodzić za pośrednictwem łącza prywatnego. Obecnie tworzenie interakcyjne za pośrednictwem usługi Azure Relay i automatyczne aktualizowanie do najnowszej wersji z centrum pobierania nie obsługuje łącza prywatnego. Ruch przechodzi przez zaporę środowiska lokalnego. Aby uzyskać więcej informacji, zobacz artykuł Azure Private Link dla usługi Azure Data Factory.
7. Link prywatny jest wymagany tylko dla podstawowej fabryki danych. Cały ruch przechodzi przez podstawową fabrykę danych, a następnie do innych fabryk danych.
8. Oczekiwana jest ta sama nazwa własnego środowiska Integration Runtime na wszystkich etapach ciągłej integracji/ciągłego wdrażania. Możesz rozważyć użycieternarnej fabryki tylko do przechowywania udostępnionych własnych środowisk Integration Runtime i używania połączonego własnego środowiska Integration Runtime na różnych etapach produkcji. Aby uzyskać więcej informacji, zobacz artykuł Ciągła integracja i dostarczanie.
9. Możesz kontrolować sposób przechodzenia ruchu do centrum pobierania i usługi Azure Relay przy użyciu konfiguracji sieci lokalnej i usługi Express Route za pośrednictwem lokalnego serwera proxy lub sieci wirtualnej koncentratora. Upewnij się, że ruch jest dozwolony przez reguły serwera proxy lub sieciowej grupy zabezpieczeń.
10. Jeśli chcesz zabezpieczyć komunikację między własnymi węzłami środowiska Integration Runtime, możesz włączyć dostęp zdalny z intranetu przy użyciu certyfikatu TLS/SSL. Aby uzyskać więcej informacji, zobacz artykuł Włączanie dostępu zdalnego z intranetu przy użyciu certyfikatu TLS/SSL (zaawansowane).