SQL Server dla One Identity Manager

SQL Server dla One Identity Manager – obecnie jedyną wspieraną bazą danych dla One IM jest MS SQL Server, ale dostępne są także inne opcje, które dziś przybliżymy.

SQL Server dla One Identity Manager -jakie bazy danych są wspierane dla wersji 10 LTS?

Jeśli sięgniecie do pierwszego artykułu z serii (One Identity Manager – historia), zobaczycie, że historia tego rozwiązania jest dosyć długa i początkowo producent wspierał dwie bazy danych: MS SQL Server oraz Oracle. Wsparcie dla Oracle’a zakończono wraz z wersją 8.0 (What is the latest supported Oracle Database Version?) i od tej pory jedyną wspieraną bazą danych jest MS SQL Server — zarówno w edycji Standard, jak i Enterprise. Dodatkowo dostępne są obecnie inne opcje, które warto uwzględnić przy projektowaniu i planowaniu wdrożenia systemu. Obecnie wspierane są:

• SQL Server
• Managed instances in the Azure SQL Database
• Azure SQL Database
• Amazon RDS for SQL Server

W dalszej części porównamy wymagania dla każdej z tych opcji i spróbujemy odpowiedzieć na pytanie, czy są tu jakieś „haczyki” do uwzględnienia.

Jakie są wymagania dla bazy SQL Server?

To opcja, którą najczęściej wybieramy przy instalacjach typu Proof of Concept (POC) oraz przy budowie środowiska do prezentacji lub nauki. W zależności od środowiska (LAB, DEV, UAT lub produkcja) trzeba pamiętać, że producent podaje rekomendowane wymagania minimalne, które w szczególności powinny być spełnione dla środowiska produkcyjnego. Dla środowisk niższych i mniej obciążonych w praktyce można przeznaczyć znacznie mniej zasobów niż rekomendowane minimum producenta (dla produkcji: 16 rdzeni CPU i 64 GB RAM).

W przypadku MS SQL Server rekomendowane jest używanie edycji Enterprise — szczególnie dla dużych instalacji produkcyjnych i wyłącznie ze względów wydajnościowych. W pozostałych scenariuszach edycja Standard będzie wystarczająca. Warto również wspomnieć o edycji SQL Server Developer, jeśli budujemy lokalny, nieprodukcyjny lab, niewykorzystywany do celów komercyjnych.

A jak wygląda kwestia bazy danych w Azure?

Tutaj robi się ciekawie, ponieważ w praktyce mamy dodatkowe opcje w modelu PaaS:

• Managed instances in the Azure SQL Database
• Azure SQL Database

Zawsze możemy skorzystać z IaaS — czyli własnej maszyny wirtualnej z zainstalowanym SQL Serverem. Jeśli jednak decydujemy się na jedną z opcji PaaS, pierwsze pytanie brzmi: czy będzie to rozwiązanie ekonomicznie opłacalne? W praktyce musimy pamiętać, że One IM wymaga In-Memory OLTP (XTP), co wymusza wybór droższych opcji: Premium (DTU) lub Business Critical (vCore). Do tego dochodzą koszty związane co najmniej z miejscem na bazę danych (uwaga na dzienniki) oraz kopie zapasowe. To, co w dokumentacji wskazywane jest jako niezbędne minimum, na które trzeba zwrócić uwagę, to:

• Dla Managed instances in Azure SQL Database: wymagany tier Business Critical
• Dla Azure SQL Database: nie jest wspierane przełączenie z General Purpose na Business Critical (czyli wybór tieru traktuj jako „na stałe” dla tej bazy)
• Dla obu z powyższych opcji nie możemy włączać funkcji Ledger database (Ledger database, updatable ledger tables, and append-only ledger tables are not supported)

Podsumowując: koszty uruchomienia samej bazy danych przy wyborze PaaS mogą być wysokie, a większą kontrolę nad kosztami zwykle daje wybór IaaS w Azure. Są jeszcze inne ograniczenia i wymagania związane z instalacją samej bazy, ale nie są one kluczowe przy podejmowaniu decyzji, co wybrać z dostępnych możliwości. Więcej szczegółów znajdziecie w aktualnych Release Notes dla danej wersji — i gorąco zachęcam do weryfikacji przy każdej zmianie wersji (żeby potem niemiło się nie zaskoczyć).

Opcja w AWS — czy są jakieś istotne różnice w porównaniu do Azure?

Standardowo (analogicznie jak w Azure) mamy możliwość uruchomienia SQL Server na EC2 (IaaS), ale wtedy sami zarządzamy Windows/SQL Serverem jak on-prem: patching, backup, HA, tuning — wszystko po naszej stronie. Jeśli to nie jest kierunek, który nas interesuje, możemy wykorzystać Amazon RDS for SQL Server, czyli zarządzaną usługę SQL, w której AWS przejmuje dużą część obowiązków operacyjnych. Trzeba jednak pamiętać o ograniczeniach:

• Ledger nie jest wspierany
• RDS nie wspiera granular permissions, więc w praktyce instaluje się schemat przy użyciu bieżącego loginu SQL (bez tworzenia dodatkowych, granularnych kont i uprawnień).

W efekcie dostajemy środowisko „SQL jako usługa”, które jest prostsze w utrzymaniu niż własny SQL na VM, kosztem części ograniczeń w modelu uprawnień.

Co jeszcze oprócz bazy danych jest nam potrzebne?

Niezależnie od tego, gdzie działa baza danych (AWS RDS for SQL Server, Azure SQL Database/Managed Instance czy SQL Server on-prem), One Identity Manager wymaga uruchomienia tych samych komponentów aplikacyjnych. Podstawą jest Job Server z usługą One Identity Manager Service oraz Application Server. Jeśli korzystamy z portali i interfejsów webowych, ich udostępnianie zapewnia API Server. Komponenty te można uruchamiać na Windows Server, natomiast w scenariuszach Linux zalecanym podejściem jest wykorzystanie kontenerów — One Identity udostępnia obrazy Dockera dla kluczowych ról (m.in. job/app/api), co ułatwia standaryzację wdrożeń i automatyzację. W rezultacie wybór platformy bazodanowej wpływa głównie na model utrzymania SQL, natomiast warstwa aplikacyjna OneIM pozostaje wymagana i powinna być zaprojektowana spójnie dla DEV/UAT/PROD, z odpowiednimi zasobami oraz bezpieczną łącznością do bazy.

Podsumowanie

Co warto zapamiętać? Nie ma jednej rekomendowanej opcji. W zależności od projektu, rozmiaru środowiska, ograniczeń kosztowych i wymagań wysokiej dostępności wybór powinien być potwierdzony solidną analizą i planowaniem. Jeśli potrzebujecie wsparcia w tym procesie, zachęcamy do kontaktu i rozmowy.