Więcej niż Chmura Prywatna - Wprowadzenie do Service Provider Foundation

Autor: Kamil Skalski

Opublikowano: 2013-03-26

Dostawcy usług mogą za pomocą technologii Service Provider Foundation (SPF) rozszerzyć swoją ofertę o rozwiązania Infrastructure as a Service (IaaS). W tym rozwiązaniu usługodawcy dostarczają interfejs, pozwalający na interakcję klientów z zasobami centrum danych. Natomiast SPF stanowi technologię pośredniczącą w komunikacji. Produkt ten, zgodnie z nazwą, stanowi podstawę do dostarczania usług, pozwalając na wykorzystanie zasobów organizacji przez klientów zewnętrznych.

System Center Service Provider Foundation wspiera budowę rozwiązań IaaS w oparciu o Virtual Machine Manager (VMM) i powiązane z nim pule zasobów, dostarczając zunifikowany interfejs komunikacji pomiędzy portalami dostępowymi klientów i infrastrukturą usługodawcy. Realizacja zadań zlecanych przez klientów usług IaaS za pośrednictwem SPF realizowana jest za pomocą skryptów PowerShell, a w przyszłości w oparciu o runbooki System Center Orchestrator. Klienci otrzymują dostęp do zagregowanego zestawu zasobów, których podział odbywa się przez klasyfikację (lub zależną od tożsamości Tenant’a) – ich lokalizacja (czy też serwer VMM, z jakiego są dostarczane) nie jest istotna. Agregacja puli zasobów jest kluczowym elementem ujednolicenia sposobu komunikacji z zewnętrznymi systemami zarządzania. SPF pozbawiony jest możliwości definiowania nowych chmur w infrastrukturze usługodawcy. Podstawową operacją jest tworzenie maszyn wirtualnych (za pomocą poleceń PowerShell). Dostęp do funkcji dostarczanych przez Service Provider Foundation odbywa się z portali zewnętrznych (App Controller lub tworzone przez dostawców, wykorzystujące mechanizmy dostarczane przez SPF), które komunikują się za pomocą protokołu OData z wykorzystaniem interfejsu REST (Representational State Transfer). Wraz z otrzymaniem polecenia wykonania operacji SPF dokonuje identyfikacji użytkownika (AuthN), np. na podstawie przedstawionego certyfikatu, oraz autoryzuje go do użycia przypisanych mu zasobów (AuthZ).

Rys. 1. Architektura System Center Service Provider Foundation.

Przekazywanie poleceń dla SPF, z wykorzystaniem protokołu OData, odbywa się poprzez dwa komponenty udostępnione przez odrębne URI (Uniform Resource Identifier):

• Admin –  związany z wykonywaniem czynności na obiektach typu tenant (SpfAdmin.Tenant), stamp (SpfAdmin.Stamp), związanych z pracą Service Provider Foundation. Dostępny pod adresem: http[s]://serwer:port/SC2012/Admin/Microsoft.Management.Odata.svc/
• VMM – pozwalający na przekazywanie poleceń do Virtual Machine Manager w celu zarządzania wirtualnymi maszynami (SpfVMM.VirtualMachines). Dostępny pod adresem: http[s]://serwer:port/SC2012/VMM/Microsoft.Management.Odata.svc/

W ramach przekazywanych poleceń możliwe jest wykonanie czterech operacji: GET, POST, PUT oraz DELETE. Dane zwracane są w formie ustrukturyzowanych danych JSON i Atom/XML.

Przykłady:

• pobranie listy wirtualnych maszyn: https://serwer:port/SC2012/VMM/microsoft.management.odata.svc/VirtualMachines
• ograniczanie ilości zwracanych informacji, o szczegółowej konfiguracji maszyn wirtualnych, do nazwy maszyny, ilości przypisanych procesorów i pamięci operacyjnej:
  https://serwer:port/SC2012/VMM/microsoft.management.odata.svc/VirtualMachines?$select=Name,Memory,CPUCount
• filtrowanie wyników wg zadanej nazwy maszyny wirtualnej:
  https://serwer:port/SC2012/VMM/microsoft.management.odata.svc/VirtualMachines?$filter=Name eq 'nazwa_maszyny_wirtualnej'

Rys. 2. Przykład pobrania danych z SPF, informacje o maszynach wirtualnych (tylko nazwa).

Najprostszy model dostarczania usług obejmuje współpracę z zewnętrznym App Controller (SCAC), działającym w infrastrukturze klienta. Service Provider Foundation, jako komponent pośredniczący w komunikacji dwóch środowisk (klienta i hostera), tworzy relacje pomiędzy jego obiektami:

• Hoster dostarcza klientom (Tenants) zasoby, zarejestrowane w Virtual Machine Manager jako „fabric”, potrzebne do tworzenia maszyn wirtualnych,
• udostępnienie następuje przez przekazanie zasobów (z przypisanymi limitami) jako pula w formie „cloud”,
• SPF rejestruje kolejne serwery VMM, dodając im znacznik (id) oraz prezentując je jako „stamps”, pozwalając tym samym na użycie ich zawartości przez odbiorców usług,
• reprezentacja serwerów VMM odbywa się z wykorzystywaniem obiektów: „servers” –definiującego adres sieciowy serwera VMM, „server stamps” – mapującego połączenie do „stamps” – będącego identyfikatorem zasobu w SPF,
• zachodzi relacja 1:1, tj. pojedynczy serwer VMM – dedykowany „stamp” w Service Provider Foundation,
• każdy obiekt „stamp” może zostać przypisany do wielu klientów „tenant” za pomocą mapowania w „tenants stamps”,
• poszczególne połączenia z App Controller definiowane są jako odrębne obiekty „tenant”, posiadające swój identyfikator, nazwę oraz wydawcę – certyfikat „issuer” pozwalający na potwierdzenie tożsamości przyłączanego serwera do SPF,
• obiekt „offer”, zawierający definicję akcji użytkownika, dostępnych sieci i wzorców oraz chmur VMM udostępnionych dla „tenant”, wykorzystywany jest dodatkowo dla określenia możliwych do wykonania czynności oraz udostępnienia zasobów infrastruktury, dostarczającej usługi w modelu IaaS,
• każda oferta powiązana jest z grupą udostępniającą pule zasobów „stamps”, czyli serwerem VMM,
• użytkownicy „tenants” mogą posiadać zdefiniowany identyfikator subskrypcji, za pomocą którego odbywać się będzie ich weryfikacja w SPF.

Warto zwrócić uwagę, że w rozwiązaniach, tj. Service Management Portal, pojedynczy użytkownik portalu może być reprezentowany jako kilka obiektów „tenant” w Service Provider Foundation oraz posiadać wiele subskrypcji.

Rys. 3. Schemat typów obiektów tworzonych w Service Provider Foundation.

Wykorzystanie SPF możliwe jest w różnych scenariuszach rozwiązań, w zależności od wielkości organizacji oraz celu implementacji rozwiązania. Jako wspólne cechy dla wszystkich wariantów wdrażania można wskazać chęć budowy spersonalizowanych interfejsów dostępowych oraz agregację zasobów. W kontekście świadczenia usług IaaS wyróżnić należy:

• tworzenie interfejsów w formie aplikacji internetowych do System Center 2012, umożliwiających dostęp do zwirtualizowanej infrastruktury, i realizację zadań Self-Service,
• zachowanie spójnego, ustandaryzowanego schematu wyglądu witryn przedsiębiorstwa – wspomaga dołączenie usług IasS do istniejącej oferty oraz dotychczas stosowanych portali dostępu użytkowników,
• Multi-tenancy – dedykowany dostępowi różnych odbiorców usług przy wyodrębnieniu mechanizmów uwierzytelnienia (brak powiązania z Active Directory) oraz izolacji zasobów,
• zarządzanie wieloma instancjami komponentów System Center, które działają w różnych centrach danych za pomocą zunifikowanego interfejsu.

Usługodawcy mogą wykorzystać także interfejsy innych produktów, np. System Center Orchestrator, w celu dostarczenia jeszcze większej funkcjonalności w ramach tworzonych portali. Interesującą alternatywą może być także wykorzystanie portalu Service Manager, działającego na podbudowie SharePoint, a następnie dostarczenie dedykowanych WebPart, pozwalających na wykonywanie operacji w SPF.