Chumra – podstawy

Chumra – podstawy

Zacznijmy od zdefiniowania podstawowego pojęcia – chmura. Jest to zasób (np. przestrzeń dyskowa, moc obliczeniowa lub aplikacja), który może zostać udostępniony użytkownikom w celu jego wykorzystania. Idea udostępniania zasobów nie jest niczym nowym w świecie IT, ale dopiero powszechny dostęp do sieci Internet oraz wysokie przepustowości łącz abonenckich pozwoliły rozszerzyć zakres działania chmury i jej możliwości. Dodatkowym bodźcem wspierającym rozwój chmury w ostatnich latach jest technologia wirtualizacji i stale rosnąca moc obliczeniowa naszych procesorów.

 

Technologia wirtualizacji

Technologia wirtualizacji odnosi się do konfiguracji i wykorzystania logicznego zasobu przez abstrakcję zasobów fizycznych. Abstrakcję zasobów można postrzegać jako możliwość utworzenia własnej konfiguracji zasobów fizycznych (np. procesora, pamięci RAM, dysku twardego) oraz możliwości zdecydowania, w jaki sposób zasoby te będą widziane i wykorzystywane przez systemy komputerowe, które będą z nich korzystać. W rzeczywistości technologia ta jest stale rozwijana od lat 60-tych ubiegłego wieku. Już wtedy inżynierowie informatyki zauważyli pewien problem dotyczący użycia zasobów ówczesnych komputerów – okazało się bowiem, że już wtedy pojedynczy użytkownik nie był w stanie w sposób ciągły wykorzystać wszystkich zasobów obliczeniowych swojego komputera. Zaczęto więc szukać rozwiązań umożliwiających wielu użytkownikom dostęp do tego samego komputera w celu bardziej racjonalnego i efektywnego wykorzystania jego zasobów – np. procesora, pamięci RAM czy dysku twardego.

Wracając do czasów współczesnych – zapewne w swoim komputerze posiadasz zainstalowany nowoczesny procesor Intel lub AMD oparty na architekturze wielu rdzeni i wyposażony w dużą ilość pamięci cache oraz RAM. Czy ktoś z Was sprawdzał, jaki procent możliwości procesora jest wykorzystywany podczas codziennej pracy? Niestety niewielki. Oczywiście niektórzy wykorzystują swoje komputery np. do grania w najnowsze gry, ale nawet w takim przypadku ciężko jest znaleźć tytuł, który wykorzystuje więcej niż 50% możliwości, jakie oferują wszystkie rdzenie nowego procesora. Logicznym podejściem wydaje się więc wykorzystanie dostępnych zasobów do uruchomienia kilku instancji systemu operacyjnego w ramach działania jednej maszyny fizycznej – w dużym skrócie na to właśnie pozwala technologia wirtualizacji.

Do podobnych wniosków doszły największe na świecie firmy technologiczne, takie jak choćby Microsoft. Gigant z Redmond posiadał dziesiątki centr danych, a więc wyspecjalizowanych serwerowni o olbrzymich rozmiarach, w których mieściło się tysiące serwerów. Microsoft i inne korporacje, takie jak VMware, IBM czy Amazon od dawna szukały możliwości na zwiększenie wydajności i rentowności swoich serwerowni. Jako cel założono efektywniejsze wykorzystanie dostępnych maszyn i ich zasobów, na przykład w taki sposób, aby minimalizować ryzyko wystąpienia sytuacji, w której 16-rdzeniowy procesor jest wykorzystywany w 10% swoich możliwości. Microsoft osiągnął swój cel poprzez rozwój własnych technologii wirtualizacji, takich jak Microsoft Hyper-V (wcześniej znany jako Virtual PC), która to technologia stała się jedną z kluczowych zalet systemów operacyjnych z rodziny Windows Server. Temat wirtualizacji jest tak ciekawy, obszerny i powiązany z wieloma technologiami Microsoft, że można by na to poświęcić osobną serię artykułów. Zapamiętajmy więc jedno – dopiero połączenie technologii wirtualizacji z dostępnymi wcześniej rozwiązaniami serwerowymi i sieciowymi pozwoliło na dynamiczny rozwój technologii chmury prywatnej i publicznej.

Chmura prywatna i chmura publiczna

Przyjrzyjmy się architekturze chmury prywatnej. Zakłada ona, że pewien zasób jest konfigurowany i udostępniany ograniczonej grupie użytkowników. Granicą chmury prywatnej jest zazwyczaj sieć LAN lub MAN. W celu zobrazowania idei działania chmury prywatnej wyobraźmy sobie najprostszy model tego typu rozwiązania – serwer plików korzystający z macierzy dysków RAID. Udostępnianym zasobem będzie tu przestrzeń dyskowa, z której skorzystać mogą wszyscy zdefiniowani wcześniej użytkownicy w obrębie sieci prywatnej. To bardzo prosty przykład, który można w jeszcze prostszy sposób rozbudować. Załóżmy więc, że w obrębie naszej sieci lokalnej działają użytkownicy, którzy korzystają z pewnej bazy danych np. Microsoft SQL Server 2014. Naszym celem jest osiągnięcie redundancji danych na dyskach, aby potencjalna awaria nie spowodowała utraty danych. Załóżmy również, że opisywana baza jest dużych rozmiarów i fizycznie będzie zajmować kilka dysków naszej macierzy RAID. Chcemy wykorzystać ten fakt w celu równoległego odczytu danych z kilku dysków jednocześnie, co znacznie przyspieszy dostęp do danych. Nie chcemy również, aby nasze środowisko było niezdatne do użytku w momencie, w którym serwer ulegnie awarii. Dlatego właśnie chcemy się zabezpieczyć na taką ewentualność. Kupujemy wtedy drugi serwer, który w razie awarii przejmie rolę głównego serwera i zapewni ciągłość pracy całego środowiska. Przy takich wymaganiach powinniśmy więc z pomocą systemu Windows Server 2012R2 skonfigurować klaster HA (z ang. High Availability) pomiędzy dwoma serwerami z zainstalowanym oprogramowaniem SQL Server 2014 oraz skonfigurować macierz do pracy np. w trybie RAID 10 (znanym też jako RAID 1+0), który zapewnia redundancję danych przy jednoczesnej wysokiej szybkości ich odczytu.

Jak widać, nasza prosta chmura prywatna zyskała bardzo ważne cechy – jest w tym momencie odporna na awarię dysków, awarię jednego z serwerów oraz zapewnia szybszy dostęp do danych niż w podstawowej wersji. W dodatku tak skonfigurowane środowisko możemy rozbudować o kolejne funkcje przydatne na przykład w sytuacji, w której nagle zajdzie potrzeba udostępnienia bazy dla większej liczby osób. W tym miejscu powinniśmy też rozważyć wady opisywanej koncepcji. Po pierwsze, w celu skonfigurowania środowiska musimy posiadać odpowiedni sprzęt, tj. serwery, oprogramowanie i urządzenia sieciowe. Wymagane jest również posiadanie odpowiednich umiejętności konfigurowania systemu, a także jego zabezpieczenia przed dostępem osób nieupoważnionych. To wszystko podnosi koszty, jakimi musimy dysponować, aby w ogóle tego typu rozwiązanie uruchomić. Jako zarządca infrastruktury odpowiadamy za koszty administracji, ale również za koszty potencjalnych awarii i związanych z nimi przestojów. Taki model administracji chmurą nazywany jest w anglojęzycznej literaturze fachowej jako „On-premisses”.

Alternatywnym modelem jest model chmury publicznej. Mamy tu styczność z zasobem udostępnianym użytkownikom za pomocą sieci Internet. Zasób jest własnością zewnętrznej firmy, której obowiązkiem jest administracja i zarządzanie całą platformą. W modelu chmury publicznej możemy więc wydzielić dwie podstawowe role – zarządca infrastruktury (administrator) i użytkownik. Dostęp do zasobu następuje po procesie uwierzytelnienia użytkownika. Użytkownik musi wcześniej założyć konto na platformie zewnętrznej firmy i zgodzić się na proponowane przez właściciela infrastruktury warunki dotyczące płatności, dostępności platformy, SLA (z ang. Service Level Agreement) i zakresu oferowanych usług. Najczęściej użytkownik zobligowany jest do opłaty jedynie za czas, w którym miało miejsce faktyczne wykorzystanie zasobów. Pozwala to na wprowadzenie oszczędności w firmach, które dotychczas używały własnej infrastruktury. Operatorzy chmur publicznych czerpią korzyści z faktu, iż mogą budować ogromne centra danych korzystając z najnowszych technologii z zakresu rozwiązań serwerowych i zarządzania energią. Zarządzanie całą infrastrukturą odbywa się w jednorodny sposób, a kolejne wdrożenia nowego sprzętu odbywają się w sposób wcześniej usystematyzowany i w bardzo dużej skali, co również przynosi duże oszczędności. Użytkownik korzystający z tego typu infrastruktury nie jest obarczony żadnymi dodatkowymi kosztami, a więc koszt uruchomienia i utrzymania własnego systemu jest relatywnie niski. Użytkownicy zyskują również bardzo poważny atut, jakim jest krótki czas wdrożenia nowego systemu. Klienci nie muszą uwzględniać czasochłonnych procesów uruchomienia i konfiguracji nowego sprzętu i oprogramowania – te procesy są wykonywane po stronie dostawcy w sposób zautomatyzowany, co powoduje, że środowisko pracy jest dostępne dosłowne w kilka minut po jego zamówieniu przez klienta. Czynniki te powodują, że rozwój chmur publicznych jest opłacalny dla obu stron – operatorów tych systemów i ich użytkowników.

W niektórych publikacjach wyróżnia się również model chmury hybrydowej, który opiera się na połączeniu obu podstawowych modeli chmury. Najczęściej model hybrydowy sprowadza się do architektury systemu, którego pewna część działa na zewnętrznej platformie sprzętowej, a pozostała część w infrastrukturze prywatnej. Ciężko jest tutaj posłużyć się jakimkolwiek przykładem, ponieważ tego typu systemy są z reguły projektowane i wdrażane indywidualnie.

Modele dostępu do zasobów chmury publicznej

Wiemy już, czym różni się chmura publiczna od prywatnej. Wiemy również, że nowoczesne chmury są oparte na systemach wirtualizowanych, co przekłada się na kolejną wartą rozjaśnienia kwestię – jak udostępniane są zasoby chmury takiej jak Microsoft Azure? Modeli dostępu do zasobów chmury jest kilka, ale trzy podstawowe to:

  • IaaS – Infrastructure as a Service – w tym modelu użytkownik chmury publicznej uzyskuje od dostawcy usługi dostęp do wydzielonego zasobu, którym najczęściej jest maszyna wirtualna (VM). Dostawca odpowiedzialny jest tylko za dostarczenie maszyny w ustalonej wcześniej konfiguracji sprzętowej oraz jej utrzymanie. Proces konfiguracji sieciowej maszyny, instalacji oprogramowania oraz jego konfiguracja jest przeprowadzana przez klienta. Przykładem tego typu zasobu w Azure jest maszyna wirtualna.
  • PaaS – Platform as a Service – model ten przewiduje udostępnienie użytkownikowi zamówionej wcześniej przez niego platformy, a więc gotowego środowiska pracy. Użytkownik nie ma prawa dostępu do maszyny wirtualnej, na której dane środowisko działa, nie może też wykorzystać tego zasobu do instalacji i konfiguracji innego oprogramowania. W tym modelu zasobu obowiązkiem dostawcy jest dostarczenie skonfigurowanej maszyny wirtualnej z zainstalowanym i wstępnie skonfigurowanym oprogramowaniem wraz z przydzielonym dostępem. Przykładem tego typu zasobu w Azure jest SQL Database, w ramach którego użytkownik zyskuje dostęp do instancji serwera SQL za pomocą interfejsu graficznego lub dedykowanego API.
  • SaaS – Software as a Service – zgodnie z tą koncepcją operator chmury publicznej zapewnia użytkownikowi dostęp do aplikacji zainstalowanej i administrowanej przez dostawcę. Można więc powiedzieć, że użytkownikowi zostaje wydzielone konto o odpowiednich prawach dostępu, które pozwala na korzystanie z udostępnionej aplikacji. Dostawca jest odpowiedzialny za proces dostarczenia maszyny wirtualnej, instalacji oprogramowania, jego konfigurację, bieżące utrzymanie, aktualizacje i wszystkie inne zadania administracyjne. Przekładem tego typu zasobu jest Microsoft Intune. Innym popularnym oprogramowaniem Microsoftu, które jest dostępne w modelu SaaS, jest dobrze nam znany Office 365.

Jak właściwie dobrać odpowiedni model zasobu do naszych potrzeb? Przede wszystkim należy zastanowić się, jakie są nasze potrzeby i priorytety. Jeśli kluczowym czynnikiem jest dla nas konfiguracja środowiska krok po kroku, poczynając od instalacji systemu operacyjnego aż do konfiguracji poszczególnych serwisów, to najlepszym wyborem będzie IaaS. Jeśli natomiast zależy nam na błyskawicznym uruchomieniu zasobu i jego szybkim wdrożeniu produkcyjnym z pominięciem czasochłonnych i schematycznych procesów instalacji – wtedy najlepszym wyborem będą zasoby dostępne w modelu PaaS. Oczywiście nic nie stoi na przeszkodzie, aby część naszego środowiska została przeniesiona do chmury jako IaaS, czyli np. w postaci maszyn wirtualnych, a pozostała część jako PaaS. Konfiguracja wszystkich rodzajów zasobów pomiędzy sobą jest możliwa dzięki sieciom prywatnym, które można skonfigurować na platformie Azure. Jeśli zaś zależy nam na dostępie do konkretnej aplikacji, a nie chcemy zajmować się jej administracją i utrzymaniem, to powinniśmy poszukać odpowiadającego nam zasobu typu SaaS.

 

źródło: centrumxp.pl

Zasoby w Microsoft Azure

Zasoby w Azure

Niezależnie od tego, jak długo korzystasz z platformy Microsoft Azure, z pewnością spotkałeś się już z terminem „model wdrożenia”. Nowym użytkownikom te słowa mogą kojarzyć się z procesem tworzenia nowego zasobu, podczas którego należy wybrać jeden z dostępnych modeli. Użytkownicy Azure posiadający nieco dłuższy staż pracy z rozwiązaniem korzystali (i być może dalej korzystają) ze starszej wersji portalu Azure i klasycznego modelu zasobów. Poniższy artykuł jest skierowany dla obu grup użytkowników i powinien rozwiać wątpliwości, dotyczące wyboru jednego z dostępnych modeli wdrożenia oraz kwestii migracji zasobów z modelu klasycznego do menadżera zasobów.

Dwa modele zasobów

Azure nie jest nową platformą – technologia ta jest rozwijana przez Microsoft od ponad 8 lat! Pierwsza oficjalna prezentacja Azure miała miejsce w 2008 roku – w świecie IT to naprawdę odległe czasy. Inżynierowie Microsoftu założyli wtedy możliwość zarządzania i komunikacji użytkownika z chmurą za pomocą dwóch podstawowych narzędzi – graficznego interfejsu użytkownika dostępnego poprzez przeglądarkę internetową oraz poprzez dedykowane API (z możliwością wykorzystania składni PowerShell). API (z ang. Application Programming Interface) to zestaw zdefiniowanych funkcji, za pomocą których można skomunikować się z danym systemem, wykonać określone akcje i przesyłać dane do i z systemu.

Warto sobie uświadomić, że portal Azure to tak naprawdę graficzna nakładka API – graficzne elementy strony służą do wywoływania tych samych funkcji, które mogą zostać wywołane przez bezpośrednie użycie programowalnego interfejsu aplikacji. W przypadku chmury publicznej Microsoftu mieliśmy do czynienia z zestawem funkcji, znanym jako Windows Azure Service Management API. Azure Service Managment oraz internetowy portal Azure pozwalały na tworzenie i zarządzanie zasobami. Narzędzia te umożliwiały wdrożenia zasobów w sposób, który dziś znany jest jako „klasyczny model wdrożenia”.

Klasyczny model wdrożenia był jedynym modelem dostępnym w ramach platformy Azure aż do roku 2014, kiedy to zaprezentowano jego nowszą wersję, znaną dziś pod nazwą “menadżera zasobów” (w wersji angielskiej “Azure Resource Manager“). Jednocześnie zaprezentowano nową wersją portalu Azure (początkowo pod nazwą „Azure Preview Portal”). Obecnie nowa wersja portalu i nowsza wersja API są domyślnymi narzędziami pracy z chmurą. Dalej jednak istnieje możliwość wykorzystania starszych wersji interfejsu. Przekonajmy się teraz, jakie są główne różnice pomiędzy „starym” i „nowym” Azure.

Klasyczny model wdrożenia

Klasyczny model wdrożenia był jedynym modelem dostępnym w przypadku korzystania ze starszej wersji portalu Azure, a współcześnie jest nadal dostępny jako alternatywna opcja do wyboru podczas procesu tworzenia zasobu w nowej wersji portalu (utworzone w ten sposób zasoby są oznaczone dopiskiem „klasyczne”). Jak już wiemy, pod nazwą klasycznego modelu kryje się starsza wersja API. Jakie były możliwości i funkcjonalności Windows Azure Service Management API? Przede wszystkim zasoby utworzone za pomocą klasycznego modelu miały swoje specyficzne ograniczenia i właściwości. Na przykład utworzenie klasycznej maszyny wirtualnej powodowało pojawienie się kilku zasobów (maszyna, dysk, karta wirtualna itd.), które nie były ze sobą w żaden sposób logicznie skojarzone. Na liście wszystkich zasobów panował więc bałagan, a administrator takiego systemu musiał na bieżąco kontrolować listę utworzonych zasobów, w szczególności w kontekście ich rozliczeń.

Azure Service Management API nie umożliwiało grupowania zasobów, co utrudniało zadania administracyjne. Sama administracja portalem była również ograniczona w zakresie przyznawania praw dostępu do kont – nie było możliwości przyznania spersonalizowanego profilu dostępu do zasobów. Omawiana wersja API nie umożliwiała zapisywania schematów zasobów i wdrażania kilku maszyn jednocześnie. Wielu użytkowników Azure skarżyło się również na konieczność tworzenia zasobu „Cloud Service” przy operacji tworzenia nowej maszyny wirtualnej. Można wypisać jeszcze kilka ograniczeń Azure Service Management API, ale to, co charakteryzuje klasyczny model wdrażania, to przede wszystkim ograniczona oferta zasobów, w szczególności po porównaniu jej z aktualnie dostępną ofertą Azure.

Z biegiem czasu (i wraz z dynamicznym rozwojem całego sektora chmury publicznej) okazało się, że za pomocą starego API nie można zaimplementować nowego typu zasobów, a przecież jednym z wyróżników platformy Azure jest ciągłe poszerzanie oferty i dostosowywanie jej do trendów panujących na rynku. Był to jeden z powodów, dla którego Microsoft zdecydował się na przedstawienie nowszej wersji interfejsu programowego i graficznego.

Menadżer zasobów

Menadżer zasobów to nowy model wdrażania dostępny w Azure. Tak naprawdę pod tą nazwą kryją się dwa pojęcia – nowy portal Azure  oraz nowy zestaw funkcji znany jako Azure Resource Manager API. W kwestii graficznej zmieniono przede wszystkim funkcjonalność górnej belki i układ bocznego menu, gdzie zastosowano rozwijane poziomy interfejsu.

Pod względem funkcjonalnym zmieniło się naprawdę wiele, a większość zmian była podyktowana sugestiami użytkowników starszej wersji Azure. Menadżer zasobów wprowadza więc możliwość grupowania zasobów, oferując tworzenie logicznych kontenerów, w których umieszczać można dowolne zasoby. Możliwe staje się masowe zarządzanie zasobami poprzez operacje na grupie zasobów (pojedyncze zasoby dziedziczą swoje prawa w zależności od praw grupy). Już podczas tworzenia nowego zasobu – np. maszyny wirtualnej – można wskazać, do której grupy ma ona należeć, lub utworzyć nową grupę. Istnieje również opcja manualnego tagowania pojedynczych zasobów, tak aby znalazły się w określonej grupie. Należy przy tym pamiętać, że jeden zasób może należeć jednocześnie do więcej niż jednej grupy.

Wprowadzono również moduł znany jako Role-based Access Control, czyli zupełnie nową funkcjonalność przypisywania praw użytkowników do zasobów z bardzo szczegółową granulacją poszczególnych opcji. Dużym udogodnieniem w stosunku do poprzedniej wersji jest obsługa schematów zasobów (ang. Templates). Schematy są dostępne w formie pliku JSON, co ułatwia ich edycję i wdrażanie. Opisując możliwości nowego API, nie sposób nie wspomnieć o możliwej integracji z oprogramowaniem Microsoft Visual Studio za pomocą dedykowanego SDK. Możliwość zarządzania zasobami Azure z poziomu IDE istniała już wcześniej, ale w obecnej wersji portalu dodano nowe funkcjonalności, które są stale rozwijane. Deweloperzy zyskali np. możliwość bezpośredniego kopiowania danych aplikacji na dedykowany ku temu zasób Azure i błyskawiczne wdrożenie działającej w chmurze aplikacji. Oczywiście w ramach nowego portalu Azure pojawiła się poszerzona oferta zasobów, która jest stale rozwijana. Dla użytkowników z Polski przygotowano polską wersję interfejsu, w przeciwności do starszej wersji portalu, gdzie nie było wyboru języka polskiego.

Co wybrać?

Czym powinniśmy się kierować podczas wyboru modelu wdrażania? W tym przypadku odpowiedź wydaje się naprawdę prosta – jeżeli nie ma powodów, by używać modelu klasycznego, to powinno się wybrać menadżera zasobów. Microsoft dosyć jasno przedstawia obecną sytuację i deklaruje, że jedynie nowa wersja portalu będzie dalej rozwijana. Jednocześnie mówi się o tym, że stara wersja Azure dalej będzie funkcjonowała, więc w żaden sposób nie zmusza się użytkowników do przejścia na nowe API. Pomimo tego firma z Redmond zaleca nowym użytkownikom korzystanie z menadżera zasobów, a tych korzystającym z klasycznego modelu zachęca do przeprowadzenia procesu migracji do nowszej wersji. Microsoft zdecydował się na wdrożenie obsługi zasobów utworzonych w ramach klasycznego modelu również w nowej wersji portalu Azure. Dzięki temu możliwe jest zarządzanie zasobami obu modeli w ramach jednego portalu. Nie oznacza to jednak, że te dwa typy zasobów są ze sobą kompatybilne. W portalu Azure pozycje menu przeznaczone do obsługi klasycznego modelu zostały oznaczone dodatkowym dopiskiem „klasyczne”, jak na przykład widoczna na ilustracji poniżej pozycja “Maszyny wirtualne (klasyczne)”.

Klasyczna maszyna wirtualna nie jest widoczna w menu przeznaczonym do obsługi maszyn wirtualnych, utworzonych za pomocą menadżera zasobów. Nie jest też możliwe skonfigurowane klasycznej maszyny wirtualnej do współpracy z siecią wirtualną, utworzoną w ramach menadżera zasobów. Nie ma możliwości konfiguracji ze sobą zasobów utworzonych w różnych modelach oraz przypisanie klasycznego zasobu do grupy zasobów. Oczywiście nic nie stoi na przeszkodzie, by skomunikować ze sobą dwie maszyny wirtualne różnego typu, ale komunikacja taka nie jest możliwa w ramach jednego zasobu sieci wirtualnej. Warto również wiedzieć, że zasoby utworzone w ramach menadżera zasobów nie są widoczne w starszej wersji portalu Azure. Podsumowując – zaleca się wykorzystywanie menadżera zasobów jako rozwiązania, które będzie dalej wspierane i rozwijane jako podstawowy model zasobów w Microsoft Azure.

Migracja z modelu klasycznego do menadżera zasobów

Jak już zostało wspomniane powyżej, są pewne argumenty za tym, by w określonych przypadkach dalej korzystać z klasycznego modelu zasobów. Przemawiać za tym może sytuacja, w której część zarządzanej przez nas infrastruktury korzysta z zasobów Azure, uruchomionych zgodnie z klasycznym modelem wdrożenia, a do tego używamy narzędzi i skryptów, dostosowanych do wymagań starszego API. W takiej sytuacji przejście na nową wersję portalu Azure i wykorzystanie zasobów, utworzonych za pomocą menadżera zasobów, wymaga opracowania nowych procedur i skryptów, zgodnych z wymaganiami nowego API. Oczywiście nic nie stoi na przeszkodzie, aby dalej wykorzystywać klasyczne zasoby, ale stwarza to opisane wcześniej problemy w zakresie współpracy z nowymi zasobami modelu wdrożenia. Dlatego, jeśli wcześniej korzystaliśmy z starszej wersji Azure, warto jest zastanowić się nad przeprowadzeniem migracji do nowego modelu.

Proces migracji może okazać się najlepszym rozwiązaniem, ale wymaga odpowiedniego przygotowania. Przede wszystkim należy posiadać aktywną subskrypcję. Następnie należy wyświetlić listę swoich zasobów utworzonych w klasycznym modelu wdrożenia i porównać ją z oficjalną listą zasobów, których migracja jest możliwa. Lista znajduje się tutaj i co jakiś czas następują na niej zmiany (najczęściej są to zmiany na plus, tj. umożliwia się migracje dla coraz większej ilości zasobów). Jeżeli któryś z naszych zasobów nie jest na liście kompatybilności, to w większości wypadków wynika to z faktu, że brak jest w modelu menadżera zasobów bezpośredniego odpowiednika tego zasobu. Zdarza się, że ta samą konfiguracja jest wspierana za pomocą innego zasobu, dostępnego w menedżerze zasobów. Można zweryfikować, czy migracja danego klasycznego zasobu w używanej przez nas konfiguracji jest wspierana, za pomocą odpowiedniego polcenia wydanego przez linię poleceń (np. dla sieci wirtualnej będzie to Move-AzureVirtualNetwork -Validate).

Kolejnym krokiem w procesie jest przygotowanie zasobu do migracji, np. poleceniem Move-AzureVirtualNetwork -Prepare. Na tym etapie możliwe jest jeszcze przerwanie procesu migracji i pozostawienie zasobów w ich obecnym stanie. Jest to szczególnie zalecane, kiedy podczas wykonywania opisanych wcześniej poleceń pojawią się komunikaty błędów. W takim przypadku najlepiej skontaktować się ze swoim Partnerem Microsoft lub bezpośrednio ze wsparciem technicznym Microsoft Azure. Zatwierdzenie procesu migracji odpowiednim poleceniem z przełącznikiem -Commit spowoduje rozpoczęcie nieodwracalnego procesu migracji do menadżera zasobów. Proces ten spowoduje chwilową niedostępność zasobów, dlatego warto go zaplanować w godzinach niskiego obciążenia naszego systemu, szczególnie w przypadku środowisk produkcyjnych.

 

źródło: centrumxp.pl

Microsoft Azure – zakładamy bezpłatne konto

Rozwiązania chmurowe to ostatnimi czasy jeden z najgorętszych tematów w sektorze IT. Co chwilę docierają do nas informacje o firmach i instytucjach, które decydują się na uruchomienie swoich serwisów za pomocą chmury.  Wielu osobom wydaje się, że chmura to bardzo droga technologia dostępna jedynie dla największych firm. Nic bardziej mylnego! Jest to przede wszystkim elastyczne rozwiązanie, które pozwala na błyskawiczne stworzenie pożądanego środowiska pracy i pełną kontrolę finansów, ponieważ użytkownik zobligowany jest do zapłaty jedynie za czas faktycznego wykorzystania środowiska. Ważnym pojęciem jest tutaj skalowalność, czyli możliwość wykorzystania atutów tej technologii w kontekście małych projektów, jak i wielkich wdrożeń. Co ważne, przejście od fazy projektowej do wdrożenia można przeprowadzić dosłownie za pomocą paru kliknięć i to bez przerwy w działaniu usługi. Tyle z teorii, a w praktyce… najlepiej przekonać się samemu. Jest ku temu świetna okazja, bowiem Microsoft oferuje darmowy kredyt w wysokości 170 euro dla nowych użytkowników platformy Azure. Poniższy poradnik pomoże Wam postawić pierwsze kroki w chmurze. 🙂

Chmura – wprowadzenie

Przed przystąpieniem do procesu zakładania konta odpowiedzmy sobie na podstawowe pytania – czym tak właściwie jest chmura, a czym Microsoft Azure? Chmurą nazywamy platformę uruchomioną na zewnętrznej infrastrukturze dostawcy usługi i udostępnioną użytkownikom w celu wykorzystania określonego jej zasobu. Zasobem chmury może być moc obliczeniowa, przestrzeń dyskowa, sieć komputerowa czy nawet aplikacja. Jednym ze sztandarowych przykładów chmury może być – doskonale znany Czytelnikom CentrumXP – Onedrive, za pomocą którego zyskujemy dostęp do wirtualnego dysku, na którym możemy składować dane. W tym przykładzie należy postrzegać udostępnioną przestrzeń dyskową jako zasób. Innym przykładem niech będzie Microsoft Word Online – za pomocą tej usługi zyskujemy dostęp do przeglądarkowej wersji programu Word, a więc zasobu udostępnionego w formie aplikacji.

Microsoft Azure to platforma obliczeniowa oferowana przez firmę z Redmond już od 2010 roku. Od tego czasu rozwiązanie te jest stale rozwijane, co uwidacznia się szczególnie w kontekście ciągłego rozszerzania oferty zasobów, które mogą być uruchomione w ramach tej platformy. Azure udostępnia narzędzia i opcje, za pomocą których możemy tworzyć, konfigurować i użytkować np. maszyny i dyski wirtualne, bazy danych czy hosting WWW. Nie sposób wymienić wszystkich możliwości, jakie oferuje nam chmura Microsoftu. Poprzestańmy więc na tym skróconym opisie i przejdźmy do procesu zakładania konta.

Proces zakładania konta Azure

Naszą przygodę zaczynamy od strony Microsoft Azure dostępnej pod tym adresem. Po wejściu na stronę powinniśmy kliknąć przycisk „Rozpocznij bezpłatnie”, za pomocą którego będziemy mogli skorzystać z aktualnej akcji promocyjnej prowadzonej przez Microsoft.

Po przejściu do następnego ekranu dowiadujemy się, że warunkiem skorzystania z promocji jest założenie nowego konta. Po spełnieniu tego warunku otrzymamy 170 euro do wykorzystania w ramach naszego konta Microsoft Azure. To właśnie chcemy osiągnąć – wybieramy więc opcję „Rozpocznij teraz”, aby przenieść się do ekranu logowania. Ci z Czytelników CentrumXP, którzy korzystali wcześniej z innych usług Microsoft (np. Outlook, Onedrive czy MVA), mogą wykorzystać swoje istniejące konto do utworzenia konta w Azure. W takim przypadku podajemy jedynie login i hasło, aby poprawnie przejść proces logowania. Czytelnicy, którzy nie posiadają konta Microsoft, mogą podać swój email i utworzyć hasło – w następnym kroku wymagana będzie rejestracja konta Mircrosoft w oparciu o podane dane. Ważną informacją jest to, że do założenia konta Microsoft wymagany jest adres email, ale nie musi to być adres utworzony w ramach usług Microsoft (Hotmail, Outlook). Możemy więc wykorzystać jakikolwiek adres mailowy – byle należał do nas. Niezależnie od tego, czy posiadamy konto Microsoft czy dopiero je tworzymy, podczas procesu rejestrowania konta Azure jesteśmy zobligowani do podania numeru telefonu i numeru karty kredytowej/debetowej. Oba te zabezpieczenia mają na celu weryfikację tożsamości. Absolutnie brak tu haczyków w postaci „po okresie próbnym automatycznie pobrana zostanie opłata”. Wyprzedzając Wasze pytanie – jeśli wykorzystamy wszystkie nasze darmowe środki, to po prostu przestaniemy mieć prawa do korzystania z zasobów, ale żadne dodatkowe obciążenia nie zostaną naliczone. Ostatnim krokiem jest akceptacja zapisów regulaminu. Jeśli podaliśmy prawidłowe dane, to w tym momencie powinniśmy uzyskać dostęp do portalu Azure. Mamy to!

Interfejs portalu Azure

Poniżej zaprezentowany został widok głównego panelu portalu dostępny pod adresem http://portal.azure.com/. Główne elementy widoku to:

  • menu boczne – daje dostęp do opcji tworzenia i konfiguracji zasobów;
  • belka górna – daje dostęp do ustawień konta, powiadomień, opcji szybkiego wyszukiwania i kontaktu ze wsparciem technicznym;
  • pulpit nawigacyjny – domyślny ekran widoczny po zalogowaniu, w podstawowej konfiguracji zawiera informacje o wykorzystanych zasobach, status serwerów, odnośnik do sklepu z dodatkami, pomoc i wsparcie. Funkcjonalność pulpitu może być rozszerzona o dodatkowe widżety;
  • podmenu – widoczne w momencie wyboru którejś z opcji z menu bocznego – daje dostęp do szczegółowych opcji zasobu.

Subskrypcja

Szczególną uwagę chciałbym poświęcić pozycji Subskrypcje (ang. „Subscriptions”). Jest to jeden z kluczowych elementów platformy Azure i warto zrozumieć jego znaczenie już przy pierwszym kontakcie z chmurą Microsoftu. Subskrypcja określa, na jakich zasadach rozliczamy się za wykorzystywane zasoby. Oczywiście istnieją różne rodzaje subskrypcji np.:

  • Bezpłatna wersja próbna – darmowa licencja oferująca kredyt 200 dolarów lub 170 euro (w zależności od regionu) dla nowych użytkowników platformy Azure;
  • MSDNAA – darmowa licencja dla studentów uczelni wyższych, które współpracują z Microsoft w ramach programu DreamSpark;
  • Pay-As-You-Go – płatna subskrypcja, w ramach której zakupiony kredyt rozliczany jest zgodnie z rzeczywistym wykorzystaniem zasobów;
  • Licencje Open – oparte na programie licencjonowania grupowego.

Aktualnie do Waszego konta przypisana została jedna subskrypcja o nazwie „Bezpłatna wersja próbna” i Wasze konto stało się domyślnym administratorem tej subskrypcji. Zarządzanie kontami i rolami w Azure to temat na osobny wpis, więc póki co warto tylko wiedzieć, że administrator subskrypcji to rola, której przysługują wszystkie uprawnienia. W menu Subskrypcje możecie również kontrolować swoje koszty, które będą naliczane zgodnie z wykorzystaniem zasobów. W ramach jednego konta można posiadać wiele subskrypcji (ta reguła nie obowiązuje w przypadku subskrypcji bezpłatnych). Przy tworzeniu nowego zasobu decydujemy, do której subskrypcji zostanie on przypisany. Daje to możliwość kontroli kosztów – przykładowo część zaawansowanych użytkowników decyduje się na przypisywanie jednego rodzaju zasobu do wydzielonej w tym celu subskrypcji. O kwestiach finansowych i dobrych praktykach zarządzania subskrypcjami z pewnością dowiecie się niedługo przy okazji kolejnych artykułów.

Korzystanie z darmowej subskrypcji wiąże się z wieloma przywilejami, ale należy również odnotować pewne ograniczenia, takie jak:

  • subskrypcja jest ważna przez okres 30 dni;
  • jeśli przed końcem ważności subskrypcji nie zostanie wykupiona kolejna subskrypcja, to utworzone zasoby i ich konfiguracje zostaną bezpowrotnie usunięte;
  • jeśli zależy nam na zachowaniu zasobów i ich ciągłości pracy, należy przed końcem darmowej subskrypcji wybrać menu Subskrypcja > Zarządzaj i tam skorzystać z opcji konwersji do płatnej subskrypcji Pas-As-You-Go.
  • nie jest możliwe wykorzystanie środków darmowej subskrypcji próbnej w celu sfinansowania zakupu w Azure Marketplace.

 

źródło: centrumxp.pl