Architekci Chmury

10 porad jak oszczędzać kasę w Microsoft Azure – do bólu i bez ściemy. Epizod 5

mifurm — Wed, 14 Jun 2017 06:20:16 GMT

Miało być 10 porad a tymczasem witam Cię już w piątym artykule o oszczędzaniu w chmurze. Jak prosto policzyć łącznie porad będzie już 15. Dziś zajmiemy się mało popularnym tematem jakim jest porządek. O tak, nie mów, że chmura kosztuje Cię dużo, skoro masz w niej mnóstwo "śmieci" i nawet nie wiesz, gdzie Twoja kasa wycieka. Zaczynamy więc.

Czy na pewno wiesz jak nazywają się Twoje zasoby i w jakich są grupach zasobów?

Wydaje się proste prawda? Dopóki masz 2 maszyny, może kilka aplikacji Web i jedną bazę, oczywiście, że Świat jest prosty. Jeśli jednak masz kilka środowisk, kilkaset zasobów i wiele grup to świat przestaje być prosty i bez dobrej konwencji nazewniczej zginiesz w tym bałaganie. Zapraszam Cię byś poczytał o tychże konwencja nazywania zasobów. Zacznij od najlepszych praktyk a potem wejdź w detale. Zapytasz co to ma wspólnego z kosztami? W chmurach praktyka pokazuje, że czas życia zasobów potrafi być bardzo dynamiczny a łatwość tworzenia zasobów sprawia, że szybko mamy ich wiele. Nie wykorzystane zasoby zbliżają nas do limitów subskrypcji, powoduję bałagan, pozostawianie danych nie w tych miejscach co trzeba i koszty. Po roku takiej "zabawy" bez kontroli ciągle nie wiadomo, czy jakieś środowisko można usunąć czy nie. Ustalenie konwencji nazewniczej, nawet najprostszej nie wymaga dużo czasu a jest zbawienne, kiedy zastanawiasz się do czego był ten dysk SSD lub ten VPN Gateway.

Ile porzuconych obiektów jest nadal w Twojej subskrypcji?

Jeśli jednak już masz dużo zasobów i nadal nie wiesz co z nimi zrobić, postaram się trochę pomóc. Napisałem serię 3 postów, które pomogą Ci odnaleźć porzucone zasoby, czyli takie, które są ale jest duża szansa, że nikt ich nie używa. Tematu absolutnie to nie wyczerpuje ale na pewno jest dobrym początkiem by zacząć, szczególnie po różnego rodzaju migracjach czy wielu próbach utworzenia środowiska. Jestem pewien, że moje proste skrypty znajdą coś u Ciebie, postaram się je dalej rozwijać. Z doświadczenia najwięcej "śmieci" pozostaje, kiedy usuwasz tylko obiekt wirtualnej maszyny ale już nie usuwasz adresu IP, karty sieciowej, kont składowania danych, być może sieci. Kiedy maszyna była w oddzielnej grupie zasobów, jest łatwo, kiedy w innej, pojawia się problem. Akurat z tak prozaiczną rzeczą moje skrypty pomogą. https://architektwchmurze.pl/2017/05/powershell-twoim-przyjacielem-jest-robimy-porzadki-w-subskrypcji/ https://architektwchmurze.pl/2017/06/powershell-twoim-przyjacielem-jest-robimy-porzadki-w-subskrypcji-cz-2/ https://architektwchmurze.pl/2017/06/powershell-twoim-przyjacielem-jest-robimy-porzadki-w-subskrypcji-cz-3/

Czy masz swój sposób kontroli kosztów? Czy używasz Tag'ów by oznaczać swoje zasoby i zrozumieć do czego ich używasz?

Dwie porady w jednym miejscu ale niezwykle ważne. Co więcej musisz mi tu wybaczyć jedną rzecz - od przybytku czasem głowa boli i tak jest w tym momencie :) W zależności od tego w jaki sposób nabyłeś subskrypcję Azure w nieco inny sposób będziesz mógł skontrolować jej koszty. Typów subskrypcji w Microsoft mamy wiele: jest MSDN, są subskrypcje wewnętrzne, tzw. Open, umowy z dużymi firmami czyli EA czy programy wspierające młode firmy jak np. BizSpark... Nie martw się:) o ile ja muszę się na tym znać, Ty lepiej:

przeczytaj ten krótki dokument https://docs.microsoft.com/en-us/azure/billing/billing-getting-started
sprawdź jakie typy subskrypcji posiadasz
i zobacz w jaki sposób będzie Ci najłatwiej kontrolować koszty.

Jeśli dopiero wybierasz model dla siebie, tu zobaczysz krótkie opisy każdego z nich. Obiecuję na tym blogu napisać kolejny artykuł o kontroli kosztów w modelu Open oraz EA, z którym pracuję najczęściej. Ponieważ się nieco różnią, będą dobrym uzupełnieniem. Ale, ale... niezależnie od tego, jaki wybrałeś model i ile masz już zasobów w Azure, chcę namówić Cię na jeszcze jedną rzecz. Drobną, nieodpłatną i łatwą do implementacji a mianowicie Tagi. Tagi pomogą Ci w odpowiedzi na pytanie (niezależnie od konwencji nazewniczej) czy dany zasób w Azure:

został powołany dla środowiska Dev, Test czy Prd. Czy też jeszcze innego, które sobie wymarzyłeś.
dotyczy aplikacji A, może B a może A, B i C
czy też może działa w ramach projektu Projekt A

Już rozumiesz? Słowem tagi pozwolą Ci przypisać dodatkowe informacje do Twoich zasobów tak, by analiza rachunku pozwoliła Ci policzyć koszty aplikacji A czy Projektu B. Ja wymieniłem te tagi, które sam proponuję ale zapewne masz w głowie inne. Zachęcam Cię byś przeczytał te dwa artykuły o wykorzystaniu Tag'ów. Pierwszy wyjaśni czym są a drugi podpowie jak użyć polityk, o których pisałem w poprzednim poście, do tego, by zawsze się pojawiły przy Twoich zasobach. Jeśli już teraz czujesz, że wolisz by ktoś tę pracę wykonał za Ciebie, postaram się pokazać dwa różne rozwiązania firm trzecich, które ułatwią kontrolę kosztów w Świecie chmury. Miało być krótko, wyszło jak zawsze. Mam nadzieję, że i tym razem znajdziesz tu coś dla siebie i od teraz będziesz bardziej świadomie wydawał swój budżet na chmurę!

10 porad jak oszczędzać kasę w Microsoft Azure – do bólu i bez ściemy. Epizod 4

mifurm — Thu, 08 Jun 2017 07:37:53 GMT

Mam nadzieję, że dotarłeś tutaj, bo czytałeś 3 poprzednie nasze wpisy na temat oszczędzania i już wiesz, że chcesz poznać więcej trików. Jeśli nie czytałeś, wróć na początek serii. Zapraszam Cię do kolejnych 3 porad ale ostrzegam :), dziś będzie nieco bardziej technicznie. Dlaczego? Bo na koniec dnia koszty Twojego środowiska w chmurze w dużej mierze zależą od tego, jak wydajnie zbudowana jest Twoja aplikacja i z jakich rozwiązań korzysta. Paradygmat o tym, że lepiej optymalizować rozwiązanie niż "dorzucać więcej mocy przetwarzania" i w chmurze jest prawdziwy. Zanim jednak wejdziemy w porady. Czy wiedziałeś, że ponad 16 usług w Azure możesz mieć zupełnie za darmo? https://azure.microsoft.com/en-us/free/pricing-offers/ Do pewnego poziomu użycia wiele usług nic nie kosztuje. Czy te darmowe oferty zawsze wystarczą by uruchomić coś produkcyjnego? Pewnie nie zawsze, ale aby poznać usługę, rozpocząć pierwsze konfiguracje czy nauczyć się choćby interfejsu, już tak.

Jeśli nie masz telemetrii w swojej aplikacji to popełniasz grupy błąd

Nie narzekaj też wtedy, że aplikacja działa wolno bo nawet nie będziesz umiał tego dobrze zdiagnozować. Zdecydowanie musisz poznać Application Insights. Nie tylko dowiesz się jakie są średnie czasy odpowiedzi Twojej strony, jak długo się ładuje, ilu ma unikalnych użytkowników ect… Najważniejszą cechą AppInsights jest to, że wykrywa sytuacji odbiegające od normy i pokazuje zależności zdarzenia od np. czasu odpowiedzi bazy czy innego serwisu z którego korzystasz. Daje to potężne wsparcie przy analizie zachowania aplikacji, rzuć okiem na przykłady App Insights Dependency. Polecam Ci też zobaczyć takie raporty jak 10 najdłużej ładujących się stron czy 10 najdłużej wykonujących się zapytań. Usługa poza zapisywaniem danych i prezentowaniem, pozwala Ci je szybko przeglądać i analizować. Narzędzie Analytics (tu masz demo https://analytics.applicationinsights.io/demo) pozwoli Ci zrobić własne analizy ale też pokaże miejsca, gdzie masz potencjalny problem (tzw. Smart Diagnostics). To nie koniec... Smart Detection samo wyśle Ci maila, jeśli zauważy, że wzrósł np. średni czas odpowiedzi. Poza tym, że dostaniesz maila, to na portalu zobaczysz na jakiej podstawie telemetria dokonała takiej analizy i pokaże Ci requesty, które za taki stan rzeczy odpowiadają. Aha, mega ważne dla tych, którzy uważają, że Azure wspiera tylko technologie z Redmond. AppInsight nie działa tylko z .Net, lista wspieranych platform jest tutaj: https://docs.microsoft.com/en-us/azure/application-insights/app-insights-platforms i co ciekawe, rozwija ją też community. Pogadajmy wreszcie o kasie. Jeden z moich klientów ma… ponad 90 usług AppInsight. Płaci tylko za 6 z nich, pozostałe 84 są nieodpłatne. Te 6 usług monitoruje serwisy produkcyjne, gdzie zbierany jest duży wolumen danych (po ok. 5GB danych telemetrycznych per serwis). Łączny koszt miesięczny jest zawrotny, mniej niż 100$. Jeśli jeszcze nie masz AppInsight a chcesz zmniejszyć swój rachunek, zobacz jak działa Twoja aplikacja i pomóż jej działać wydajniej.

Architektura Twojej aplikacji powinna umiejętnie korzystać z chmury

Ta porada powinna, tak naprawdę. być pierwsza. Architektura aplikacji to będzie przecież to, od czego zaczniesz budowę swojej aplikacji. Warto przy tej okazji zadać sobie kilka pytań:

Czy Twoja aplikacja musi korzystać z dysków SSD w maszynie wirtualnej by uzyskać odpowiednią wydajność przy odczycie danych? Warto pamiętać, że zwykły Storage Account ma wydajność nawet do 20 000 IOPS i kosztuje Cię ok. 0.02$ za GB za miesiąc z naliczaniem dziennym.
Może zamiast VM'ki możesz skorzystać z usług PaaS dla dostarczania Twojej aplikacji? Wydajność będzie podobna ale koszt utrzymania PaaS (vs. IaaS) jest niższy. Pamiętaj, że nie jest istotne ile usługa kosztuje ale jakie jest jej Total Cost of Ownership. Dla usług Web, API czy Backend usługi PaaS są dla mnie naturalnym wyborem.
A co powiesz o koncepcji Serverless? Jeśli nie wiesz czym są funkcje to błąd. I to duży. Nie twierdzę, że od razu cała Twoja aplikacja zostanie przepisana na funkcje ale zobaczy czym one są i jaki jest ich model kosztowy. Po przykłady wyliczeń zapraszam Cię tutaj: https://azure.microsoft.com/pl-pl/pricing/details/functions/. Jeśli nie wiesz jak zacząć z Functions, polecam Ci blog Gutka. Oczywiście, niektórzy powiedzą, że Serverless jako koncepcja jest młoda, świeża i jeszcze ma wiele "niewygód". Dyskusje pewnie można toczyć długo ale nikt nie odbierze funkcjom tego, że są tanie. Bardzo tanie i bardzo przejrzyste w swoich kosztach.
Boisz się, że Twoją aplikację zabije duża liczba requestów? Zobacz Azure API Managemenet. Serwis jest mało popularny w Polsce a pozwala Ci wystawić bramkę przed Twoim API, która za Ciebie wykona autoryzację zapytań, ograniczy limit zapytań czy wreszcie pozwoli Ci wystawić to samo API w różnych wersjach na świat. Narzędzie o potężnych, a mało znanych możliwościach.

Chcesz więcej? Czy sprawdzałeś kiedyś jak działa Azure Tables? Co ty na to, by była to twoja prosta baza dla parametrów konfiguracji? Szybkie, tanie i łatwe w kodowaniu. Potrzebujesz kopiować dane po wielu kontach danych czy kopiować dane z DocumentDB? Azure Data Factory - znowu niezwykle tanie i bardzo pomocne przy wielu scenariuszach, a rzadko wykorzystywane. Robisz replikację Azure SQL do innego ośrodka? A czy wiesz, że baza w drugim ośrodku może być mniejsza (np. S0 zamiast S3)? Takich pytań możemy postawić sobie wiele. Zanim zbudujesz aplikację w chmurze, zbuduj architekturę swojej aplikacji i sprawdź czy Twoje architektoniczne decyzje mają sens ekonomiczny. Warto zainwestować w kogoś, kto Ci pomoże w tym procesie. ROI dla takiej inwestycji jest nie policzalne, szczególnie na początku.

A środowisko zapasowe? Nie wycierajmy sobie twarzy koncepcją "Infrastructure As a Code"jeśli z niej nie korzystamy.

Środowisko zapasowe w tradycyjnym jego rozumieniu nie pasuje nieco do modelu chmurowego. Pytanie… czy naprawdę musisz mieć cały czas dostępne środowisko działające w drugim regionie? Nie wystarczy Ci np. replika danych do tego regionu czy kopie zapasowe? Jeśli boisz się, że całe DC wyleci w powietrze poza Backupem użyj DataFactory i kopiuj dane w inne miejsce. Pomyśl tak... być może możesz:) "oskryptować" tworzenie tego środowiska i stworzyć je, gdy będzie taka biznesowa potrzeba. "Infrastructure As a Code" to potężna koncepcja i trzeba nauczyć się z niej korzystać. Serio. Rzuć okiem na krótki a potężny wpis. Wraz z jednym zespołem przygotowaliśmy skrypt do postawienia środowiska w drugim ośrodku, ustawiliśmy "deployment" paczek z kodem, przygotowaliśmy skrypty do migracji parametrów, skrypty do rozgrzania aplikacji, ect. Efekt jest taki, że od momentu podjęcia decyzji o migracji do czasu postawienia drugiego, pełnego rozwiązania mija mniej niż 2 godziny a ciągle kilka zadań możemy zoptymalizować. Fajnie prawda? Najlepsze jest to, że za to drugie środowisko nie płacę dopóki nie muszę go postawić. To była już 12 porada, przed nami jeszcze kilka. Epizod 5 już się pisze i to nie jest nasze ostatnie słowo! Miłego oszczędzania.

10 porad jak oszczędzać kasę w Microsoft Azure – do bólu i bez ściemy. Epizod 3

Bartlomiej Graczyk — Mon, 05 Jun 2017 14:38:30 GMT

Licencje, ach te licencje...

Temat licencjonowania rozwiązań w chmurze publicznej może nie jest specjalnie złożony, ale na pewno można go długo analizować. Na początku roku napisałem nawet kilka artykułów na sql4You.info, które dość głęboko traktują temat - przy okazji zachęcam do lektury, warto zacząć od wprowadzenia: https://sql4you.info/2017/01/20/ask-me-anything-licencjonowanie-rozwiazan-w-chmurze/ Celem dzisiejszej publikacji, nie jest zdecydowanie ponowny opis teorii (o tym powyżej), a weryfikacja, jak różne modele licencjonowania wpływają na rzeczywiste koszty wykorzystania rozwiązań "w chmurze". Aby ułatwić Ci jednak przejście przez poniższe scenariusze esencja wiedzy o modelach licencjonowania w Azure w formie uproszczonego diagramu: O czym zatem przeczytasz poniżej - wszystko na przykładzie Windows Server oraz SQL Server:

Scenariusz 1 - Przykładowy koszt rozwiązania w chmurze w przypadku licencji wraz z uruchamianym rozwiązaniem
Scenariusz 2 - a może jednak licencje własne
Scenariusz 3 - wybrałem opcję licencjonowania - chcę, aby było jeszcze taniej - czy to się uda?

Do określenia ceny musimy przyjąć pewne założenia, wykorzystamy je we wszystkich scenariuszach. W naszej analizie wykorzystamy jedną z mniejszych maszyn wirtualnych: D3: 4 rdzenie, 14 GB RAM. Region: Europa Północna (jak już Michał zauważył w poprzedniej części REGION MA ZNACZENIE ) Maszyna działa non stop, czyli 744 godziny miesięcznie. Ilość użytkowników: 100 Zakładamy potrzebę uruchomienia serwera na potrzeby bazy danych - SQL Server. Wymagane standardowo w takim scenariuszu licencje to:

Windows Server oraz SQL Server
Licencje dostępowe CAL dla Windows Server

Scenariusz 1 - Przykładowy koszt rozwiązania w chmurze w przypadku licencji wraz z uruchamianym rozwiązaniem ?

Na początek pierwsza dobra wiadomość - w przypadku wykorzystania Windows Server na platformie Azure nie interesują nas licencje dostępowe(CAL), tym samym już na starcie, w porównaniu do rozwiązania we własnej serwerowni, odnotowujemy - 100(ilość użytkowników z naszego założenia) x koszt licencji Windows CAL z Software Assurance ( ~ 52,44 EUR). Całkiem nieźle - zaoszczędzamy 5244 EUR Jeszcze do niedawna jedyną możliwością uruchomienia środowiska na platformie Azure, wykorzystującego Windows Server było skorzystanie z maszyny wirtualnej z takim właśnie systemem. Licencja na wykorzystanie systemu Windows Server wliczona w cenę maszyny wirtualnej pozwala zaadresować wszelkie wymagania w tym zakresie i co ważne pozwala skorzystać z Windows Server "na godziny" , czyli płacimy tylko wtedy kiedy maszyna wirtualna działa. Jak skorzystać z tej opcji i ile to kosztuje? Cena naszej maszyny z systemem Linux to: 183,21 EUR/miesiąc Natomiast cena z systemem Windows Server Datacenter to: 323,75 EUR/miesiąc Zatem Windows Server w tym przypadku to koszt 140,54 EUR/miesiąc. Warto w tym miejscu zauważyć, że mówimy o Windows Server DATACENTER Edition oraz braku dodatkowych kosztów związanych z licencjami dostępowymi (CAL) - tak, tak podkreślę to raz jeszcze, w przypadku wykorzystania Windows Server w środowisku Azure nie są wymagane licencje dostępowe(CAL). Nasz scenariusz wymaga jednak wykorzystania dodatkowo SQL Server. Jako, że przyjęliśmy wykorzystanie licencji dostarczanych z maszyną wirtualną mamy do dyspozycji trzy edycje Microsoft SQL Server. W momencie tworzenia maszyny wirtualnej wybieramy spośród dostępnych obrazów, które zawierają wspomniany SQL Server. Warto w tym miejscu podkreślić, że możemy skorzystać z edycji dopasowanej do swoich potrzeb wybierając pomiędzy edycjami Enterprise, Standard lub Web (ta ograniczona wyłącznie do zastosować w przypadku rozwiązań takich jak portale, aplikacje WEB) Na potrzeby naszej kalkulacji przyjmijmy edycję Enterprise. Przy tej edycji, koszt wybranej maszyny wirtualnej to: 1 264,87 EUR/miesiąc. Zatem koszt SQL Server Enterprise to 941,12 EUR/miesiąc. Licencje dostępowe CAL do SQL Server w tym scenariuszu nie występują, zatem nie uwzględniamy ich w rozliczeniu. Reasumując całkowity, miesięczny koszt rozwiązania Scenariusza nr 1 to 1 264,87 EUR/miesiąc. W kolejnych punktach będziemy posługiwali się kosztem 24 miesięcznym, ze względu na Software Assurance dołączane do licencji, zatem przyjmijmy, tutaj również koszt 24 miesięczny: 30 356,88 EUR

Scenariusz 2 - a może jednak licencje własne

A co jeśli już jakieś licencje posiadamy. Czy możemy je wykorzystać? TAK, ale.... w tym celu należy posiadać licencje z aktywnym pakietem Software Assurance. Wymaganie to dotyczy zarówno Windows Server jak i SQL Server. W przypadku Windows Server dostępny jest benefit o tajemniczej nazwie Hybrid Use Benefit. W tej nazwie kryje się prawo wykorzystania licencji Windows Server, którą już posiadamy. W przypadku licencji na edycję Standard można korzystać z licencji we własnym datacenter lub zamiennie w Azure. Natomiast przy edycji Datacenter, dla każdego zestawu(16 licencji na rdzenie) możemy uruchomić środowiska równolegle - we własnym środowisku i Azure (np. 1 maszyna 16 rdzeni lub maksymalnie dwie maszyny po 8 rdzeni każda). Jako, że w scenariuszu nr 1 wykorzystaliśmy edycję Datacenter kontynuujemy jej użycie również tutaj. W momencie tworzenia maszyny wirtualnej pojawia się pytanie: Można też skorzystać z gotowego obrazu oznaczonego jako HUB Jak to się przekłada na koszt maszyny? Bardzo prosto - maszyna w ramach, której korzystamy z benefitu HUB, jest rozliczana wg kryteriów maszyny z systemem Linux. Efektywnie oznacza to koszt 183,21 EUR/miesiąc, zatem 4 397,04 EUR/ 24 miesięce Tym razem jednak musimy zadbać o licencję Windows Server (co prawda zakładamy jej posiadanie, natomiast samo nabycie licencji, wiązało się z jej nabyciem). Korzystając ze standardowych cen cennika Open, Windows Server Datacenter z Software Assurance (16 rdzeni, to minimalna ilość licencji jakie można nabyć na Windows Server 2016), to koszt ~ 8512,29 EUR / SA na 24 miesiące. Dodatkowo SQL Server Enterprise (4 core), którego koszt wraz z SA na 24 miesięcy to 37 680,50 EUR Zatem sumarycznie koszt rozwiązania w Scenariuszu nr 2 to ~ 50 589,83 EUR / 24 miesiące Uwaga! Ceny do kalkulacji wg: https://windows2016server.pl/cennik-Windows-Server-2016-commercial.html https://sql2016.pl/cennik-sql.html

Scenariusz 3 - wybrałem opcję licencjonowania - chcę, aby było jeszcze taniej - czy to się uda?

Wybór pomiędzy Scenariuszem nr 1, a scenariuszem nr 2 pozostaje kwestią mocno uzależnioną od faktu czy te licencje w ogóle posiadamy. Niezależnie jednak od wybranego scenariusza, powstaje pytanie. Czy możliwe jest obniżenie kosztu samego środowiska uruchamianego w Azure, w rozumieniu wykorzystywanej maszyny wirtualnej. Odpowiedź TAK - będąc klientem z umową Enterprise Agreement, możesz skorzystać z oferty Compute Pre-Purchase. Korzystając z opcji CPP, zamawiasz dedykowane SKU(pozycja w cenniku), która obejmuje 744 godziny/miesiąc działania wybranej przez Ciebie instancji maszyny wirtualnej. Warto wspomnieć, że CPP nie wchodzi w wartość tzw. monetary commitment, jest to element umowy EA porównywalny np. z planami Office 365(które też mają swoje SKU). Należy również zapamiętać, że:

Instancje nabyte w ramach CPP nie mogą być zmienione po realizacji zakupu.
Okres rozliczeniowy CPP to 12 miesięcy.

Jakiej zniżki można się spodziewać? ceny poszczególnych instancji w ramach CPP pozwalają na ograniczenie ich kosztu o nawet 63%. W opisywanym przez nasz przypadku oznacza to możliwość zejścia z kosztem do poziomu 67,78 EUR/miesiąc działania maszyny D3 (z systemem Linux) + koszty licencji Windows/SQL Server w scenariuszu 1 lub 2 na zasadach opisanych powyżej.

Czy zatem można oszczędzać na Azure uwzględniając odpowiednią konfigurację licencyjną?

Zdecydowanie! Jak widać na przykładach, różnice to nawet nie pojedyncze dolary, a kilkaset czy nawet kilka tysięcy dolarów dla pojedynczej maszyny wirtualnej działającej przez 744 godziny miesięcznie,przez okres 2 lat. Moim zdaniem temat na prawdę wart uwagi. Na koniec jeden komentarz. Charakterystyka Twoich środowisk, może być zupełnie inna, niż opisane powyżej scenariusze. Tym samym finalne wartości jak i różnice w kosztach mogą być różne - weź to pod uwagę. Weź również pod uwagę, że w przypadku porównania z własnym rozwiązaniem należy uwzględnić również koszt własnej infrastruktury, który zupełnie został tutaj pominięty - w rzeczywistości nie da się go pominąć. Rozważasz, planujesz, a może już uruchamiasz środowisko w chmurze - porozmawiaj o tym z Partnerem Microsoft lub bezpośrednio z nami - jesteśmy do Twojej dyspozycji. A jeśli chcesz zgłębić kwestie aspektów licencyjnych polecam serię ASK ME ANYTHING na sql4you.info: https://sql4you.info/2017/01/30/ask-me-anything-mobility-partner-potrzebny-od-zaraz/ https://sql4you.info/2017/02/15/ask-me-anything-uslugi-w-chmurze-publiczne-a-licencje-czy-sa-w-ogole-potrzebne/

10 porad jak oszczędzać kasę w Microsoft Azure – do bólu i bez ściemy. Epizod 2.

mifurm — Fri, 02 Jun 2017 00:49:45 GMT

Cześć. Witam Cię w drugim odcinku na temat zaciskania portfela. Jeśli nie widziałeś pierwszego odcinka, rzuć okiem na to. Zanim przejdziemy do meritum... 1) W poniedziałek do naszej serii ze swoim postem dołączy Bartek Graczyk i opowie Wam m.in. o licencjach w chmurze. Mega istotna sprawa, tam dopiero można oszczędzać. 2) Zapewne nie zmieścimy się w 10 radach, bo mamy ich w zanadrzu więcej :). Liczymy, że jeśli pracujesz z chmurą Azure, dołączysz się do Nas i podzielisz się dobrą praktyką z innymi. A dziś...

Azure daje Ci nieodpłatnie usługę Azure Advisor... która sama mówi jak oszczędzić w chmurze.

Advisor jest przydatny nie tylko pod kątem kosztów. Rzuć okiem na mój zrzut ekranu. W przypadku kosztów Advisor sprawdza wzorzec wykorzystania maszyny wirtualnej ale również usług PaaS pod kątem użycia procesora ale również I/O na dysku. Jego rekomendacje pokazują:

maszyny o bardzo niskiej utylizacji, które albo możemy zmniejszyć albo wyłączyć
bazy danych Azure SQL, które zamiast wielu separowanych baz, można połączyć w pulę baz, korzystających z wspólnej puli zasobów.

Co ciekawe, Advisor po wejściu w daną rekomendację pokaże Ci dane, z których rekomendacja wynika jak również potencjalne oszczędności. Usługa się rozwija więc zapewne więcej analiz będzie dostępnych w przyszłości.

Dzięki tzw. politykom możesz ograniczyć miejsca tworzenia usługi, typ usługi czy jej wielkość

Wiele osób po pierwszym wejściu na portal Azure boi się, że od razu stworzy usługę, która w godzinę zje cały dostępny budżet lub powołane usługi znajdą się np. w Azji. Warto wtedy sięgnąć po Azure Policies. Po pierwsze, nic nie kosztują:) Po drugie możesz ograniczyć na poziomie regionu lub grupy zasobów lokalizację usług, typy usług czy wreszcie nawet ich dopuszczalne parametry. I nie musisz od razu znać PowerShell czy JSON aby to zrobić, tu przykład ustawiania polityki na grupie zasobów. Możliwości jest wiele a więc warto rzucić okiem na dokumentację. Idealny sposób na to by kontrolować nowych użytkowników świata chmury bez odbierania im pierwszego dnia dostępu do portalu.

Usługi PaaS mają inny model biznesowy. Nie można ich wyłączyć, można co najwyżej zmienić ich poziom, by ograniczyć koszt.

Wiele osób bywa zaskoczonych takim stanem rzeczy. Ale nawet Ci zaskoczeni nie zmieniają tego poziomu usługi a ta cały tydzień kosztuje ich tyle samo, a to poważny błąd. Jeśli używasz App Service, sprawdź obciążenie swojej usługi na (CPU Time, Memory) na przestrzeni tygodnia. Jeśli np. wieczorami usługi nie potrzebuje dużej liczby instancji albo zadowoli się niższym poziomem, to warto poświęcić chwilę na napisanie skryptu w Azure Automation i taką zmianę wykonywać. Popatrz niżej. Instancje są naprawdę różne i mają różny zakres funkcjonalny. Pod kątem wydajności P1 jest tak samo wydajne jak S1 czy B1. Serio, testowałem. O ile B1 nie posiada Slotów i Traffic Managera (obie usługi uważam za genialne) to już S1 i P1 są funkcjonalnie takie same, różnią się ilością tychże slotów, instancji, częstością backupu ect. A więc przenosząc się pomiędzy nimi i badając liczbę instancji na pewno możesz oszczędzić. Skalowanie w górę i w szerz w AppService jest szybkie więc nie bój się, że wpłyniesz na swoją aplikację. Podobnie sprawa się ma z Azure SQL. Rzuć okiem na zrzuty z kalkulatora. Jeśli Twoja baza ma rozmiar do 250 GB to znowu znajdziesz aż 4 różne poziomy cenowe. Najtańszy kosztuje 0,02 EUR za godzinę, najdroższy 0,17 EUR za godzinę. W skali 744 godzin w miesiącu to jest 8 krotna różnica. Nic nie stoi na przeszkodzi by Twoja aplikacja używała bazy na poziomie S3 od poniedziałku do piątku, a w piątek o 24 rozpoczynała weekend zmniejszając się do S0. Tylko na tej prostej operacji w skali miesiąca oszczędzisz prawie 30 EUR. Gdybyś zmniejszał poziom usługi co noc po 22 i przywracał o 6 rano, to w skali miesiąca oszczędzisz prawie 53 EUR czyli prawie 50% kosztów usługi. I to tylko na jednej bazie. Zakładam, że już rozumiesz koncepcję. To samo zrobisz np. z Cosmos DB, MySQL, Postgress, nawet z ASE się uda, choć potrwa chwilę dłużej. 3 krótkie porady za nami. Kolejne 3 powinny pokazać się w wtorek. Miłego oszczędzania, w końcu weekend przed nami!

10 porad jak oszczędzać kasę w Microsoft Azure - do bólu i bez ściemy. Epizod 1.

mifurm — Mon, 29 May 2017 11:43:32 GMT

Jeśli zaczynasz z chmurą Azure, musisz to przeczytać. Korzystasz od dawna? Przeczytaj i sprawdź czy stosujesz wszystkie aspekty, które pomogły innym.Jeśli tematy wydajności środowiska, kontroli kosztów i planowania są Ci bliskie to post jest dla Ciebie. Postaramy się w 10 prostych krokach pokazać Ci, jak możesz zmniejszyć swoje łączne koszty nie tracąc nic z wydajności! Na początek 3 pierwsze porady. Zaczynamy!

Wybór lokalizacji usług ma znaczenie.

Do wyboru jest 38 regionów. Ceny pomiędzy regionami z definicji są RÓŻNE. Nie wiedziałeś o tym? Sprawdź kalkulator. Szybko dowiesz się, że generalnie w Europie najtaniej jest w Irlandii, drugie miejsce należy do Amsterdamu, potem UK oraz Niemcy. Im droższy zasób tym różnica może być wyższa. Wejdź na kalkulator i zacznij sprawdzać. Wybór regionu to też inny czas dostępu do usługi. Jeśli Twoi klienci są w Polsce, prawdopodobnie nie warto stawiać usługi w US. Chcesz mieć szybko, sprawdź Azure Speed Test i wybierz odpowiedni region dla siebie.

Jeśli już korzystasz z maszyn wirtualnych to magiczne dopiski v2 mają znaczenie.

Jeśli i Ty wybierając maszynę wirtualną masz syndrom "po co tego jest tyle" to absolutnie się tym nie przejmuj :). Rodzin maszyn jest i będzie dużo, zapewne będzie więcej. Zastanawiasz się jaka jest ich wydajność - musisz zajrzeć tutaj. Jeśli tylko możesz, bierz maszyny z serii v2. Mają szybsze serie procesorów, działają na nowszym sprzęcie i kosztują tyle co maszyny bez v2 albo... taniej :). Właśnie tak. Maszyna D1v2 jest ok. 4 EUR tańsza niż D1 w Europie Północnej na moment pisania tego posta.

Czas działania maszyn to kluczowa pozycja na Twoim rachunku za chmurę

Niby wszyscy to wiedzą, mało kto stosuje. Zapamiętaj: koszt maszyny w Azure naliczany jest za każdą minutę, kiedy pracuje. Dokładnie tak, dokładność jest minutowa a więc jest o co walczyć. Jeśli mi nie wierzysz, zobacz krótki przykład, na warsztat weźmiemy maszynę D2v2.

Koszt 1 godziny w North Europe tej maszyny z licencją na Windows Server to: 0,21 EUR. Koszt miesięczny to ok. 153 EUR
Koszt 1 godziny w North Europe tej maszyny z darmową dystrybucją Linux: 0,11 EUR. Koszt miesięczny to ok. 76 EUR
Wg. Kalendarza Świąt w Maju 2017 mamy 21 dni roboczych i aż 10 dni wolnych.

I co z tego? Rozważamy kilka scenariuszy, zakładając, że miesiąc ma 4 tygodnie:

Twoje środowisko w ciągu dnia pracuje tylko 12h
Twoje środowisko potrzebuje wysokiej wydajności przez 12h a przez kolejne 12h wystarczy mu duża niższa wydajność
Twoi developerzy pracują w modelu 5x12h, a poza tym środowisko nie jest wykorzystywane

Teraz w zależności od scenariusza liczba godzin, w których Twoja maszyna musi być włączona:

12h x 7 dni x 4 tyg. = 336h dla maszyny D2v2. Koszt: 70,56 EUR, oszczędzasz 64%.
336h dla maszyny D1v2 i 336h dla maszyny D2v2. Koszt: 104.1 EUR, oszczędzasz 32%
240h dla maszyny D2v2. Koszt: 50.4 EUR, oszczędzasz 68%

To przykład. Twój scenariusz aplikacji jest na pewno bogatszy i inny. W przypadku usług PaaS jest nieco inaczej, o tym opowiem Ci w kolejnym poście. Jeśli masz raptem kilka maszyn wykorzystaj opcję Auto-Shutdown VM ale dla aplikacji i większej liczby maszyn pomoże Ci Azure Automation. Zapewne zastanawiasz się ile kosztuje Cię Azure Automation? 500 pierwszych minut w miesiącu jest nieodpłatne, kolejne 1000 minut kosztuje... 2 dolary. Na pewno Cię na to stać. Zainteresowany kolejnymi rekomendacjami? W kolejnym poście pogadamy o politykach, maszynach pracujących 24x7, licencjach na Windows Server, usługach PaaS i telemetrii.

Skalowalne środowisko do przechowywania obrazków

Kamil Brzezinski — Mon, 08 May 2017 21:38:20 GMT

Przechowywanie plików w bezpieczny sposób we własnej serwerowni to nie lada wyzwanie dla każdej dużej firmy. Wymagane są ogromne inwestycje nie tylko w macierze dyskowe, ale również pozostałą część infrastruktury. Do tego przy projektowaniu takiego rozwiązania należy też wziąć pod uwagę bezpieczeństwo danych, czyli także kopie zapasowe. Jeśli serwis szybko rośnie i użytkownicy umieszczają coraz więcej plików planowanie takiej architektury może być trudne. Z pomocą przychodzą rozwiązania w chmurze. Wyobraźcie sobie duży portal internetowy, który odwiedzany jest codziennie przez wiele milionów internautów. To może być serwis społecznościowy, strona z najnowszymi plotkami o gwiazdach, ale też duża platforma e-commerce z ogłoszeniami. Co jeśli takich plików użytkowników mamy kilka miliardów. Jeśli każdy obrazek w Internecie ma średnio 100kB otrzymujemy setki terabajtów danych nie tylko do przechowania, ale przede wszystkim udostępnienia w sieci. Jak wyskalować rozwiązanie które ma przechowywać np. 500TB plików, które będzie w stanie obsłużyć 5 miliardów zapytań miesięcznie? Rozwiązań jest wiele – skupmy się jednak na najprostszym, ale najskuteczniejszym. Wykorzystać w tym celu możemy Blob Storage. Blob Storage świetnie nadaje się do przechowywania:

Dokumentów
Danych społecznościowych takie jak zdjęcia, wideo, muzyka i blogi
Kopii zapasowych plików, komputerów, baz danych i urządzeń
Obrazów i tekstów dla aplikacji sieci Web
Danych konfiguracji dla aplikacji w chmurze
Danych big data takich jak dzienniki i inne duże zestawy danych

W zależności od tego jak często chcemy dostawać się do danych wybrać musimy jedną z opcji. Oczywiście mając do dyspozycji wersję „Hot” i „Cold” wybierzemy tą pierwszą, ponieważ do drugiej mamy chociażby wyższe ceny dostępu, bo jest stworzona z myślą o przechowywaniu kopii zapasowych, niż plików o bezpośrednim dostępie. Musisz pamiętać, że wysyłanie danych do chmury jest bezpłatne, płaci się tylko za pobieranie danych. Ponieważ każdy z magazynów ma limit przechowywanych danych warto od razu założyć kilka kont i na nich pracować. Domyślnie każde konto ma limit 500TB danych. Nawet jeśli zakładamy, że mamy mniej danych do przechowania warto założyć kilka oddzielnych kont, żeby ruch rozłożyć pomiędzy oddzielnymi kontami. Nie ma co przejmować się limitem kont bo możemy mieć ich aż 200 na każdej subskrypcji Konta mają ograniczenie też co do ilości zapytań. Na szczęście dla magazynów typu blob każde konto ma aż 20 tysięcy zapytań na sekundę co daje nam ponad 53,5 mld zapytań miesięcznie. Nasze założenia to ponad 5 mld odwołań czyli 1/10 możliwości konta. Jednak dla zapewnienia sobie odpowiedniej wydajności i pojemności najlepiej założyć i tak minimum 2 konta, a przy tej skali działalności sugerowałbym max 10. Każdy storage może mieć ustawioną politykę replikacji. Najniższą i najtańszą opcją jest LRS czyli „Local-reduntant storage” – tutaj nasze dane mają kilka kopii w ramach jednego data center. Opcją droższą, ale bezpieczniejszą jest GRS i RA-GRS. Oba robią kolejne kopie w zapasowym DC, a RA-GRS dodatkowo umożliwia nam wybranie z którego miejsca chcemy każdorazowo sięgać po plik. Dostęp do plików odbywa się na podstawie unikalnego linka (w przypadku bloba publicznego) lub klucza jeśli używamy blob storage w trybie „Private”. Do naszego celu odradzam kontener publiczny, bo każdy będzie mógł nie tylko anonimowo odczytać plik, ale też wylistować wszystkie nasze pliki w katalogach. Jeśli planujemy więc udostępniać użytkownikowi bezpośredni dostęp do pliku jedyna opcja to „Public blob”. Publiczne adresy zawsze są w formacie https://.blob.core.windows.net// Chyba, że użyjemy opcji „Custom domain” możemy wtedy „ukryć” domyślny adres platformy Microsoft Azure za własną domeną. Jeśli zaś pliki chcemy zakryć np. za proxy (o tym później) to idealny jest tryb „Private”. Możemy też użytkownikowi dać tymczasowy dostęp do prywatnego pliku korzystając z "Shared Access Signature" gdzie możemy określić też czas dostępu, po którym link wygaśnie. Do kont możemy dostać się za pomocą API lub gotowych bibliotek dla większości popularnych języków programowania takich jak PHP, .NET, Node.js, Java, C++, Python, Ruby i inne. Aby podejrzeć zawartość naszego katalogu w chmurze możemy użyć bezpłatnego oprogramowania dla Windows o nazwie „Microsoft Azure Storage Explorer”. Każde konto ma po dwa klucze dostępu „Access keys”. W przypadku, kiedy zmieniamy jeden z kluczy aplikacja powinna automatycznie łączyć się korzystając z drugiego. Dzięki temu, nasz serwis będzie zawsze udostępniał pliki nawet podczas rutynowej zmiany haseł dostępów. Dostęp do kluczy mamy z poziomu Portalu Azure lub skryptów PowerShell. Wspomniałem wcześniej o tym, że moglibyśmy chcieć ukryć pliki za proxy. Możemy to zrobić z kilku powodów. Jednym z nich mogą być koszty transmisji danych, innym własna sieć CDN. Jeśli mamy własne DC, w którym chcemy hostować proxy możemy między serwerownią, a Azure uruchomić łącze MPLS czyli ExpressRoute. Dzięki temu będziemy mieć gwarantowaną przepustowość, ale też możemy nie płacić za przesłane dane. Pewnie zastanawiasz się w jaki sposób przesłać wiele terabajtów danych do Azure? Nic trudnego. wystarczy skorzystać z usługi Azure Import/Export czyli wysłać do serwerowni Microsoftu dyski twarde z danymi. Więcej o usłudze dowiesz się pod dedykowaną stroną. W ten sposób można szybciej i wygodniej przesłać duże ilości danych nie obciązając łącz in ternetowych. Rozwiązań hostowania plików dla dużego serwisu internetowego jest wiele. Blob Storage wydaje się najprostszy, najtańszy i najbardziej uniwersalny, dlatego postanowiłem go opisać. Chętnie w komentarzach przeczytamy jakie wy macie wyzwania z przechowywaniem plików w swojej firmie i chętnie doradzimy jak sobie z nim poradzić korzystając z Microsoft Azure.

Zbieranie oraz analizowanie logów wykorzystując produkt Log Analytics.

Błażej Miśkiewicz — Fri, 14 Apr 2017 08:41:10 GMT

Log Analytics Analiza logów jest bardzo istotnym elementem w życiu wielu organizacji. Jednym ze sposób zbierania a następnie analizowania logów czy danych wydajnościowych jest wykorzystanie produktu o nazwie Log Analytics. Produkt Log Analytics jest częścią pakietu o nazwie Microsoft Operations Management Suite (OMS), w skład pakietu OMS wchodzi dodatkowo Azure Site Recovery, Azure Automation, oraz Azure Backup. Produkty te można kupić oddzielnie lub jako jeden łączny pakiet adresujący wiele problemów informatycznych. Log Analytics może zbierać dane pochodzące z maszyn fizycznych jak również z maszyn wirtualnych. Maszyny te mogą być zainstalowane w lokalnym centrum danych jak również w chmurze. Rozpoczęcie pracy z produktem Log Analytics możemy zacząć od wykorzystania gotowych paczek rozwiązań które bardzo szybko pozwalają zacząć analizowanie naszego środowiska. Gotowe paczki rozwiązań posiadają często wiedzę bezpośrednio od inżynierów firmy Microsoft. W paczce zaszyte są informacje co należy zbierać z systemów jak również jak to przedstawić w ładny graficzny sposób. W wielu przypadkach konfiguracja paczki rozwiązań polega po prostu na jej dodaniu, w innych przypadkach należy wykonać konfigurację, która jest bardzo dobrze opisana w dokumentacji. Na poniższych zdjęciach został umieszczony widok gotowych paczek rozwiązań, widok ten szybko się zmienia więc w chwili czytania tego artykułu ilość paczek może być znacznie większa. Jedną z możliwości gotowych paczek rozwiązań jest weryfikacja konfiguracji naszego środowiska Active Directory Domain Services, Microsoft SQL Server oraz produktu System Center Operation Manager. Paczki tego typu oznaczone są jako Assessment (np. AD Assessment). W przypadku błędnej konfiguracji usługi Active Directory Domain Services, Microsoft SQL Server czy System Center Operation Manager, gotowa paczka rozwiązań informuje nas o problemie, jak również przedstawia informacje jak taki problem należy rozwiązać. Kolejną paczką, na którą warto zwrócić uwagę to „Security and Audit” jest ona niezbędna w każdej organizacji, gdzie chcemy badać zachowania dotyczące użytkownika takie jak np. błędne logowania, zmiana czy reset hasła użytkownika. Dodatkowo dzięki technologii „Threat Intelligence” zawartej w paczce „Security and Audit” jesteśmy w stanie zobaczyć połączenia przychodzące z zainfekowanych źródeł (np. z komputerów należących do Botnet-ów), jak również połączenia wychodzące ze stacji/serwerów do zainfekowanych źródeł. Informacje dotyczące połączeń z zainfekowanymi komputerami dostępne są w postaci mapy widocznej na poniższych rysunkach. Następną bardzo istotną gotową paczką jest „Change Tracking”. Rozwiązanie to przedstawia nam obraz zmian wykonywanych na monitorowanych serwerach czy stacjach roboczych. Śledzone zmiany dotyczą usług, aplikacji, aktualizacji oraz zdefiniowanych plików. Inne paczki rozwiązań dostarczają nam możliwość monitorowania środowiska sieciowego w lokalnym centrum danych, jak również w Microsoft Azure. Kolejnym przykładem jest możliwość analizowania środowiska Microsoft Hyper-V oraz VMware. Posiadacze Office 365 są w stanie podłączyć swoją organizację do Log Analytics i zobaczyć w przejrzysty sposób logi z tego produktu. Wykorzystując integrację Log Analytics z Upgrade Readiness jesteśmy w stanie wykonać analizę naszego środowiska stacji roboczych pod kątem potencjalnych problemów podczas migracji z systemów Windows 7, 8, 8.1 do Windows 10. Dzięki gotowej paczce „Service Map” w graficzny sposób możemy zobaczyć udane połączenia, jak również połączenia nieudane z punktu widzenia procesów uruchomionych na systemach Linux lub Windows. Mapa usług wykrywa automatycznie komponenty aplikacji i mapuje komunikację pomiędzy usługami. Istnieje wiele innych paczek rozwiązań służących np. do weryfikacji aktualizacji naszego środowiska Windows oraz Linux czy np. paczka wyświetlająca informację o wykrytych wirusach (integrujemy się obecnie z Symantec Endpoint Protection, Trend Micro Deep Security oraz z Windows Defender). Nie jestem jednak w stanie przedstawić wszystkich możliwości produktu, dlatego też, aby przestudiować wszystkie możliwe paczki proponuje zapoznać się z linkami które umieściłem na dole dokumentu. Brak gotowych paczek rozwiązań nie jest przeszkodą w analizie logów. Produkt Log Analytics dostarcza nam możliwość konfiguracji jakie dodatkowe logi czy dane wydajnościowe za wyjątkiem tych zbieranych przez gotowe paczki, mają trafić do produktu Log Analytics. Istnieje możliwość zbierania logów niestandardowych, które muszą być dostępne w postaci plików tekstowych. Wykorzystując opcję niestandardowe pola jesteśmy w stanie wyodrębnić z logu informacje które nas interesują i zrobić z nich pole możliwe do przeszukiwania. Technologia wyodrębniania danych z logu i tworzenia nowego pola nazywa się FlashExtract. Używając „View Designer” jesteśmy w stanie za pomocą języka zapytań przedstawić graficznie analizowane logi. Język zapytań jest na tyle prosty, że już po kilku godzinach spędzonym z produktem jesteśmy wstanie bardzo szybko pisać własne zapytania, poniżej kilka przykładów zapytań. Wyświetlanie licznika wydajności, czas procesora na wykresie. Type=Perf (ObjectName=Processor) CounterName="% Processor Time" | measure avg(CounterValue) by Computer Interval 24HOURS Wyświetlenie wszystkich stacji na których ilość wolnego miejsca dla dysków G oraz E jest mniejsza niż 3000 MB. Type=Perf ObjectName=LogicalDisk CounterName="Free Megabytes" (InstanceName="G:" OR InstanceName="E:") AND CounterValue < 3000 Zaczęły pojawiać się również paczki tworzone przez firmy trzecie, przykładem takiego rozwiązania jest paczka OpsLogix Microsoft OMS Log Analytics Solution która przedstawia informację na temat środowiska Oracle, link do rozwiązania na dole artykułu. Monitorowane środowisko może składać się z systemów Windows, jak również Linux. Dostępni są agenci do ściągnięcia bezpośrednio z portalu, a dla użytkowników, którzy wykorzystują już produkt System Center Operation Manager, dodanie agentów sprowadza się do wpisania danych dostępowych do Log Analytics w portalu administracyjnym System Center Operation Manager. Agent dla Log Analytics jest tym samym agentem, który wykorzystywany jest przez produkt System Center Operation Manager. Istnieje możliwość zbierania danych Simple Network Management Protocol (SNMP), które pochodzą z urządzeń sieciowych. Do zbierania danych SNMP można wykorzystać SNMP trap receiver o nazwie snmptrapd który jest popularnym rozwiązaniem możliwym do uruchomienia na systemie Linux. Więcej informacji o zbieraniu danych z urządzeń sieciowych można znaleźć w linku na dole artykułu. Produkt Log Analytics posiada możliwość wysyłania alertów na maila, a wykorzystując produkt Azure Automation mamy możliwość wykonywania skryptów w Microsoft Azure lub w środowisku lokalnym. Dodatkowo jesteśmy w stanie wykorzystać opcję webhook czyli wysłać żądania HTTP POST na jakiekolwiek zewnętrzne źródło które tylko obsługuje tego typu połączenia. Do webhooka jesteśmy w stanie dorzucić JSONa z różnymi informacjami które chcemy przekazać. Istnieje możliwość uruchomienia widoków z Log Analytics na urządzeniach mobilnych. Dostępna jest opcja udostępnienia danych z Log Analytics w PowerBI, co zapewnia dodatkowe możliwości analizy oraz prezentacji danych. Log Analytics posiada API zarówno dla wyszukiwania (log search REST API) jak i na potrzeby wrzucania danych (HTTP Data Collector API). Dzięki takie podejściu wiele problemów dotyczących zbierania danych jesteśmy w stanie rozwiązać wykorzystując np. język PowerShell. Produkt Log Analytics nie wymaga zakupu czy instalacji nowej infrastruktury fizycznej. Całe środowisko do analizy logów dostępne jest w centrum danych Microsoft Azure. Produkt Log Analytics działa jako usługa, dlatego też nie martwimy się oszacowaniem wydajności środowiska. Produkt jest usługą, która ma trzymać swoje parametry i zapewnić sprawnie działający system do analizy logów. Uruchomienie produktu Log Analytics i jego wstępna konfiguracja zajmuje zazwyczaj kilka godzin, dzięki temu można od razu zaobserwować wyniki działania produktu. Produkt Log Analytics jest jednym z najszybciej rozwijających się produktów dostępnych na platformie Microsoft Azure. W każdej chwili istnieje możliwość przetestowania produktu wykorzystując link https://experience.mms.microsoft.com po wypełnieniu formularza dostajemy się do wstępnie skonfigurowanego środowiska Log Analytics. Dla osób, które chcą przetestować rozwiązanie dla swojej własnej infrastruktury dostępna jest darmowa wersja produktu Log Analytics, za pomocą której można wysłać łącznie 500 MB logów dziennie, jedynym wymaganiem jest posiadanie subskrypcji Microsoft Azure. Artykuł miał na celu tylko przybliżenie możliwości produktu, w celu dokładnego przejrzenia produktu zapraszam na poniższe strony które ja dość często wykorzystuję. Dokumentacja produktu https://docs.microsoft.com/en-us/azure/operations-management-suite/operations-management-suite-overview Blog grupy produktowej https://blogs.technet.microsoft.com/msoms/ OpsLogix Microsoft OMS Log Analytics Solution https://www.opslogix.com/use-the-opslogix-microsoft-oms-solution/ Zbieranie danych z urządzeń sieciowych https://blogs.technet.microsoft.com/msoms/2016/09/21/collecting-snmp-data-with-operations-management-suite/

O konfiguracji sieci w Azure App Service Enviroment słów kilka. A może więcej niż kilka.

mifurm — Wed, 01 Mar 2017 07:23:30 GMT

Jeśli czytaliście mój poprzedni artykuł o budowaniu aplikacji w chmurze bez użycia serwera to zapewne wiecie, że…App Service Enviroment to dedykowane środowisko dostarczające z jednej strony, łatwość wdrażania aplikacji, właściwe dla zwykłego App Service, ale pozwalające dużo bardziej precyzyjnie sterować ruchem sieciowym. Banał, w dodatku wszystkie aspekty tej konfiguracji opisane są w dokumentacji Azure (trzeba przyznać, że nie w jednym a kilku artykułach) a jednak pierwsza konfiguracja i zrozumienie o co chodzi może młodemu (nie wiekiem a doświadczeniem) adeptowi sztuki nastręczyć nieco trudności. Zróbmy więc to krok po kroku ale najpierw nieco teorii i wyjaśnień jak to działa. Jeśli nie interesuje Cię teoria (nie rozumiem dlaczego miało by tak być:)) ale chcesz zrobić tak, by działało, przejdź od razu do zrzutów z mojej konfiguracji. Zachęcam jednak by poświęć chwilę i zrozumieć szczegóły, grafiki zapożyczyłem od Christina Compy, która decyduje o rozwoju ASE.

Po pierwsze, ASE zawsze powstaje w ramach dedykowanego subnet'u w ramach wybranego VNET'u.

Cała infrastruktura dedykowanych maszyn wirtualnych w ramach klastra, na których "stoi" Wasze ASE występuje właśnie w tej sieci. Cała komunikacja sieciowa, jaka wchodzi do ASE odbywa się przez tzw. VIP czyli Virtual IP, który jest publiczny i widoczny z Internetu. To stanie się niezwykle istotne w drugiej części artykułu. Dokumentacja o tym pisze tak: Architektura sieci w ramach ASE.

Jeśli tworzycie nowe ASE, polecam wcześniej utworzyć VNET w wybranym regionie a w nim Subnet, w którym Wasze ASE będzie gościło.

Nie polegajcie na kreatorze Azure, który utworzy dużą sieć (/16 jeśli mnie pamięć nie myli) i zawsze z tą samą adresacją wewnętrzną (nie jest to problem dopóki nie chcecie korzystać z Express Route lub VNET Peering). I tutaj kilka rekomendacji:

Wasz Subnet musi być tak duży, by pomieścić wszystkie nody ASE, o które w przyszłości powiększycie Wasze środowisko. Jeśli dziś Wasze ASE ma tylko 2 instancje w ramach puli FE i 2 instancje w WP1 (jest to minimalny rozmiar ASE), a w przyszłości dojdziecie do maksymalnych 50 instancji to Wasza sieć musi być na to gotowa, inaczej się NIE "wyskalujecie". Proponuję by też VNET, w ramach którego tworzycie ASE miał unikalną adresację (bo patrz pkt 2.) na wypadek gdybyście kilka ASE chcieli przez ER wystawić do Waszego DC.
Nie da się na dziś zmienić sieci (VNET, Subnet) w któym występuje Wasze ASE. Jeśli je chcecie zmienić ze względu na adresację, wielkość musicie usunąć środowisko i powołać od początku.
Jeśli Wasze ASE ma być dostępne przez ExpressRoute to sieć, której będziecie używali nie może występować po stronie Waszego DC. Niby oczywiste prawda? ;)
Microsoft zaleca by subnet, w którym wdrażacie ASE był pusty, inaczej w przypadku problemów Support może odmówić wsparcia . Skoro MSFT oficjalnie zaleca to nie ma co dyskutować, szkoda czasu :)
Jeśli chcecie by Wasze ASE było dostępne tylko dla rozwiązań w ramach Azure (nie dostępne z Internetu) lub tylko przez sieć w ramach ExpressRoute wtedy zależy Wam na ILB (Internal Load Balancer) w ramach ASE. Opcja dostępna tylko przy tworzeniu ASE, potem oczywiście nie ma opcji zmiany.

I na koniec, możliwy jest również scenariusz, w którym jedno ASE jest "publiczne", drugie "dostępne tylko w Azure" i Wasza aplikacja jest rozłożona pomiędzy tymi warstwami ASE. Poglądowo wygląda to tak jak niżej. Na dziś jest to dość kosztowna opcja, jak pamiętacie, najmniejsze bazowe ASE "pochłonie" ok. 1200 banknotów z podobizną Washington'a. Skoro już wiemy, jak utworzyć nasze ASE poprawnie, to teraz przejdźmy do naszego realnego scenariusza. To, co chcemy osiągnąć, jest zilustrowane na rysunku poniżej:

Tylko wybrane aplikacje, wdrożone na ASE są dostępne z Internetu. Inne, "prywatne", są dostępne tylko z publicznej aplikacji w ramach ASE.
Ruch do publicznej aplikacji, wdrożonej na ASE może przyjść tylko z WAF'a (Web nie Windows:) Application Firewall) lub innego "appliance", wdrożonego w Azure. Na rysunku poniżej brakuje wspominanego WAF - wiadomo, że stoi pomiędzy ruchem z Internetu a VIP
I na koniec… każdy ruch, który nie przeszedł przez WAF'a, a próbuje odpytywać przez VIP naszą publiczną aplikację, powinien być terminowany na poziomie sieci Vnet (Subnet) a nie na poziomie samej aplikacji publicznej. Zaleta moim zdaniem niedoceniona, a przecież nie możliwe do zrealizowania w zwykłym AppService i takimi zapytaniami może generować niepotrzebną utylizację zasobów AppService i w szczególności doprowadzić do niedostępności usługi. AppService nie ma pojęcia sieci, którą może sterować i jedyna konfiguracja wyłączająca konkretne adresy IP może odbyć się na poziomie Web.config.

Możecie ten scenariusz jeszcze bardziej rozbudować, a mianowicie: 1. W moim podejściu tylko jedna (publiczna co zrozumiałe) będzie miała własną nazwę / domenę i będzie dostępna pod publicznym adresem IP 2. Ponieważ ASE może być duże, możecie mieć kilka aplikacji publicznych, każda pod inną, własną domeną, ale wtedy musicie skorzystać z tzw. IP-SSL Binding i zwiększyć liczbę publicznych adresów przypisanych do waszego ASE. Jest dostępna taka opcja w głównych opcjach ASE pod nazwą IP addresses. Domyślnie macie tylko jeden taki adres, dodanie kolejnego potrafi potrwać chwilę. Możecie postawić podchwytliwe pytanie: kiedy następuje operacja wiązania kolejnego publicznego IP z wybraną nazwą własną i czy muszę to wywołać przez portal / skrypt PowerShell? Odpowiedź: przy dodawaniu kolejnej nazwy własnej do aplikacji (co zobaczycie poniżej) następuje powiązanie tej nazwy z adresem IP (sam Azure to robi), co jest ładnie widoczne w opcji IP addresses, o której pisałem wyżej. Posiadanie wielu adresów z wieloma nazwami własnymi daje jeszcze jedną elastyczność - możecie przypisać różne reguły dla ruchu wchodzącego/wychodzącego per aplikacja (a tak naprawdę per przypisany do niej adres IP). Bierze się to stąd, że cały ruch wewnątrz ASE pomiędzy aplikacjami następuje zawsze z VIP i do VIP przypisanego do aplikacji. Ruch wewnątrz ASE nie wychodzi poza wskazany dla ASE subnet ale jest tak oznaczany w nagłówkach TCP IP i dlatego też możliwe jego rozróżnienie.

Prześledźmy zrzuty ekranu z konfiguracji, którą wykonałem. W mojej konfiguracji dodatkowo dodałem certyfikat SSL na poziomie VIP'a w ramach ASE, zalecam jednak terminację SSL robić na WAF i nie ustawiać jej już na poziomie VIP'a. Pokażę to w kolejnym poście.

Pierwszy krok to ustalić VIP naszego ASE, którzy przy okazji jest adresem wychodzącym, z którego wychodzi cały ruch wychodzący z ASE.
Jeśli już powołaliście swojego WAF'a do życia i udało Wam się zalogować do konsoli (tutaj dla Barracuda) musicie dodać nowy serwis. Ważne: Żeby określić Waszą usługę przez adres IP a nie nazwę musicie włączyć w Barracuda tzw. Advanced Mode w ustawieniach konfiguracji samej Barracuda. Tutaj link jak zacząć z Barracuda WAF.
Czas dodać własną domenę do naszej aplikacji w ramach ASE. Nic trudnego, tak samo wygląda to dla App Service.
Dodajemy host name, potwierdzamy, że jesteśmy właścicielami domeny. U dostawcy domeny zmieniamy rekord tylko na czas ustawienia tego poświadczenia. Docelowo przecież moja nazwa dla aplikacji czyli michal.architektwchmurze.pl nie będzie rozwiązywana na VIP dla ASE a na... adres publiczny WAF lub adres publiczny Load Balancera, który "stoi" przed parą WAF'ów.
Efekt powinien być taki jak niżej. I tu właśnie doskonale widać, że moja nazwa rozwiązuje się na adres publiczny WAF'a. Możecie zapytać - to po co ta cała zabawa z potwierdzeniami domeny? To trochę tak, jak ustawianie "custom host header" w serwerze aplikacyjnym, dzięki któremu wiemy jak rozróżnić wiele różnych żądań po porcie 80 z jednoczesnym potwierdzeniem, że macie prawa do tej właśnie publicznej nazwy.
A teraz pobawimy się siecią. O tym jak kontrolować sieć w ramach ASE więcej tutaj Jak kontrolować ruch wchodzący do ASE. Kluczowa z całego artykułu jest tabelka jak niżej, która pokazuje porty, używane przez ASE. Na czerwono te obowiązkowe, w szczególności 454, 455, które jeśli nie są dostępne, są blokowane, to wtedy Wasze ASE pokaże w portalu, że ma wewnętrzny problem albo że jest niedostępne. I tu ciekawostka, domyślnie sieć dla ASE nie ma przypisanego NSG, kiedy dodacie do niej własne NSG to już te porty powinny być tam przez Was określone. Azure nie zrobi tego sam.
Ja wykorzystałem jedno z NSG, które już było w mojej subskrypcji. Co tu mamy:
- Pozwalam na ruch po porcie 80 i 443 z mojego WAF.
- Pozwalam na ruch po 454 oraz 455 tu oznaczony jako Internet ale ten ruch zawsze będzie z portu VIP.
- I niepotrzebnie pozwalam na ruch po porcie 3389 - tak to jest, jak korzysta się z już dostępnego NSG.
- Aby nie popełnić mojego błędu i zrobić to w 100% profesjonalnie, waszym przyjacielem będzie PowerShell, opisany znowu w tym samym artykule: Jak kontrolować ruch wchodzący do ASE
I teraz już tylko przyjemności: dodanie do wybranego przez Was subnetu utworzonej wcześniej Network Security Group
Sprawdzenie, że przypisanie odbyło się poprawnie.
I testy - najpierw staram się dostać do mojej aplikacji przez publiczny adres DNS, który jest przypisany każdej web aplikacji w ASE (o ile nie występuje z ILB)

A teraz dostaję się do mojej aplikacji po mojej własnej nazwie i domenie i jest... Aplikacja odpowiada. Skąd mam pewność, że ruch idzie przez WAF? Bo jak widzieliście wcześniej michal.architektwchmurze.pl wskazuje właśnie na mojego WAF.

Na dziś koniec. Jak kontynuację tego postu, pokażę Wam jak do tej konfiguracji dodać certyfikaty. Zachęcam do własnych zabaw i pytań. Temat w gruncie rzeczy jest prosty, wymaga jednak chwili, by zrozumieć teorię.

Raporty i analityka sprzedaży w hurtowni danych Azure

Maciej Stopa — Tue, 21 Feb 2017 13:14:49 GMT

Prowadząc analitykę sprzedaży, często zachodzi potrzeba porównania specyficznych metryk rok do roku. Jeżeli dodatkowo ilość transakcji jest z miesiąca na miesiąc coraz większa, klasyczne środowisko analityczne które projektowaliśmy i wdrożyliśmy kilka lat temu zaczyna nam niedomagać. Potężne serwery z ogromną ilością pamięci RAM oraz wydajne przestrzenie dyskowe wydają się być dosyć stare. Koszty utrzymania także nie są niskie. Przeliczanie kostek OLAP o setkach miar odbywa się w weekend i musi być gotowe na poniedziałek rano, aby można było rozpocząć pracę. Trwa to jednak coraz dłużej. Dodatkowo proces raportowania zaczyna przeciążać serwery w ciągu normalnego tygodnia pracy. Stajemy przed dylematem: spróbować optymalizacji schematów i modeli danych, co pozwoli przetrwać jeszcze 3-4 miesiące, zainwestować w kolejny sprzęt który będzie w pełni wykorzystywany tylko w weekend, czy może spróbować zmienić podejście i wykorzystać chmurę Azure.

Wspólnie z kilkoma klientami podjęliśmy dyskusję, która ostatecznie obróciła się w warsztaty Proof of Concept. Wśród kilku możliwych scenariuszy wybraliśmy dwa, które cechują się różnym stopniem skomplikowania, wpływającym także na szybkość wdrożenia:

Scenariusz 1 - Dobudowanie kolejnego serwera OLAP w Azure jako maszyny wirtualnej i rozkładanie obciążenia dla raportowania w ciągu tygodnia pracy

Zalety:

Szybkie wdrożenie – zestawienie VPN, utworzenie instancji OLAP, ładowanie danych – kilka dni
Prawdopodobnie szybsze przeliczanie kostek OLAP
Możliwość dynamicznego reagowania na zwiększone zapotrzebowanie na moc i pojemność – skalowanie instancji i dokładanie kolejnych dysków

Wady:

Istniejące problemy ze strukturami i modelami danych pozostają, przez co środowisko nadal będzie się rozrastało a przetwarzanie trwało coraz dłużej
Potrzeba wdrożenia mechanizmu rozkładania ruchu dla użytkowników raportowania

Scenariusz 2 - Budowa rozwiązania w oparciu o skalowalne usługi Azure SQL Data Warehouse i Azure Analysis Services oraz wykorzystanie raportowania w PowerBI

Zalety:

Migracja do architektury MPP (trochę więcej o samej usłudze klasy MPP można przeczytać tutaj) dla hurtowni danych oraz modelu tabular dla usługi analitycznzych
Dynamika skalowania wydajności na poziomie przesuwania suwakiem DWU oraz QPU
Eliminacja drogich w utrzymaniu serwerów i macierzy w lokalnych centrach przetwarzania danych
Duża elastyczność budowania raportów w PowerBI
Raporty PowerBI dostępne przez Internet, także na urządzenia mobilne

Wady:

Konieczność zaplanowania odpowiednich mechanizmów dystrybucji danych dla architektury MPP
Wymaga zaangażowania klienta oraz partnera, który przygotuje nowy lub dostosuje obecny model danych, przeprowadzi testy i przeniesie raportowanie do PowerBI – kilka do kilkunastu tygodni

Sprawdzamy scenariusz 1

Składniki:

Azure VPN Gateway - Route Based High-Performance
Azure Virtual Machine - GS2 -> GS5, MSSQL 2016 Enterprise
Azure Storage - 8x P30
Azure Automation - Start/Stop/Skalowanie
Azure Log Analytics - na potrzeby analizy logów, głównie MSSQL
Azure Virtual Network - oczywiście :)

Użytkownicy korzystający z kostek OLAP autoryzują się przy pomocy klasycznej domeny Active Directory, zatem należy zapewnić możliwość połączenia z sieci lokalnej do Azure, ale i w przeciwną stronę - na potrzeby dostępu do Active Directory. Do testów posiadaliśmy dosyć szybkie łącze do Internetu, zestawiony został Azure VPN Gateway w trybie Route-Based i rozmiarze High-Performance, co dało wydajność na poziomie 200Mb/s. W zupełności wystarczyło to do załadowania danych do kostek OLAP w Azure i nie powodowało znaczących opóźnień przy pobieraniu wyników przez użytkowników końcowych.

Utworzona została maszyna GS2 z MSSQL Server 2016 Enterprise. Aby zapewnić wydajność dla danych, dołączone zostało 8 dysków P30 (SSD) w stripingu. GS2 jest najmniejszym rozmiarem maszyny serii G do którego możemy dopiąć 8 dysków dla danych, a w przyszłości skalować w górę do GS5. Dołączona została do Azure Log Analytics na potrzeby zbierania i analizy logów.

Ciekawostka zaobserwowana w trakcie testów, to że na potrzeby rozwiązania zastosowana została maszyna GS5, która de facto nie była odpowiednikiem obecnie stosowanych serwerów we własnej infrastrukturze. Konfiguracja GS5 to kilka razy mniej pamięci RAM oraz znacznie mniejsza moc obliczeniowa, która w efekcie pozwoliła osiągnąć zbliżony do obecnie uzyskiwanego czas procesowania kostek. Istotny jest również fakt, że użytkownicy łączący się do kostek OLAP za pośrednictwem Excel'a dostępnego na własnych stacjach roboczych uzyskiwali wydajność zbliżoną, a niejednokrotnie większą niż w przypadku obecnie stosowanych serwerów. Wniosek z obserwacji jest bardzo prosty. Uwzględniając niewielki nakład pracy udało się zapewnić porównywalny wydajnościowo dostęp do zasobów OLAP. Z perspektywy skalowalności rozwiązań tej klasy jest to bardzo istotny argument, pozwalający na wykorzystanie platformy Azure jako naturalnego rozszerzenia własnej infrastruktury przy zachowaniu pełnej kompatybilności rozwiązania z obecnie stosowanymi narzędziami.

Po przetestowaniu wydajności serwera w Azure, po stronie klienta skonfigurowany został prosty load balancer oparty o HAProxy, dzięki czemu użytkownicy byli równomiernie rozkładani pomiędzy serwerem lokalnym a serwerem w Azure. Zapewniło to przezroczystość użytkowania takiego rozwiązania ale i dodatkową elastyczność. W razie gdyby zaszła potrzeba wyłączenia któregoś z serwerów, użytkownicy będą kierowani na drugi. Łatwo także dodać do takiego scenariusza kolejne serwery.

Całość rozwiązania była szczególnie zadowalająca ze względu na prostotę i szybkość wdrożenia. Pozwoliła na odciążenie serwerów lokalnych w przeciągu kilku dni. Niestety, podobnie jak środowiska w lokalnych centrach danych, przez wykorzystanie instancji maszyn wirtualnych - jest to najmniej elastyczne i optymalne kosztowo rozwiązanie. Można oczywiście używając Azure Automation startować/zatrzymywać serwery czy zmieniać ich rozmiar, ale jest to w pewnym stopniu mniej automatyczne niż pozostałe scenariusze.

Sprawdzamy scenariusz 2

Składniki:

Azure SQL Data Warehouse - 100->1000 DWU
Azure SQL Database
Azure Data Factory - wraz z Data Management Gateway
Azure Storage
PowerBI - interaktywne raportowanie i wizualizacja danych

Scenaiursz numer 2 to o podejście o jeden, a nawet kilka kroków dalej, niż scenariusz 1. Pierwszy krok to zmiana lokalizacji hurtowni danych stanowiącej źródło danych dla kostek analitycznych. W scenariuszu nr 1 hurtownia danych pozostawała cały czas na lokalnych serwerach firmy. Tymczasem w tym podejściu zdecydowaliśmy się na jej przeniesienie na platformę Azure, co więcej ze względu na wolumin danych (5 TB) oraz wymagania w zakresie wydajności rozwiązania zdecydowaliśmy się na wykorzystanie SQL Data Warehouse. W tym miejscu pojawiła się konieczność pierwszej ze zmian - sposób zasilania hurtowni. DWH wymaga zasilenia danymi z baz źródłowych. Wykorzystaliśmy do tego Azure Data Factory który w dosyć przyjemny sposób pozwala na kopiowanie danych pomiędzy różnymi bazami danych, a w naszym wypadku, do DWH. Wykorzystując Data Management Gateway, będący częścią Azure Data Factory, nie musieliśmy zestawiać dedykowanej komunikacji VPN, ponieważ Data Management Gateway zapewnił zabezpieczenie transmisji danych.

Warto w tym miejscu podkreślić, że w pełną efektywność architektury MPP, w jakiej działa SQL Data Warehouse, uzyskujemy poprzez zrównoleglenie operacji na niezależnych węzłach obliczeniowych(compute nodes), w tym również ładowania danych. Właśnie dlatego ładowanie odbywało się z wykorzystaniem funkcjonalności Polybase, która korzystaja z bezpośredniego dostępu do zasobów obliczeniowych usługi (compute node). Korzystając z tego podejścia udaje się osiągnąć imponujące wyniki. Co więcej już w tym miejscu jesteśmy w stanie wykorzystać benefit łatwości skalowania usługi i na czas ładowania danych "podkęcić" hurtownię wydajność hurtowni. W naszym przypadku nie było to nawet konieczne, a przeładowanie dziennej partii danych (ok 6 GB), zajęło nieco ponad 60 minut ( uwzględniając transfer danych z serwerów wewnątrz obecnej infrastruktury i ograniczenia łącza internetowe). W przypadku architektury MPP kluczem do sukcesu jest stosowana dystrybucja danych. Dystrybucja w przypadku SQL Data Warehouse zawsze odbywa się pomiędzy 60 baz danych, które obsługiwane są w obrębie dostępnych węzłów obliczeniowych usługi. Skalowanie usługi (zmiana ilości DWU), to zmiana ilości węzłów obliczeniowych, ale również reorganizacja dystrybucji pomiędzy dodawane/odejmowane węzły.

Mając dane odpowiednio załadowane do hurtowni przystąpiliśmy do kolejnego kroku - udostępnienie danych ma potrzeby analizy i raportowania użytkownikom końcowym. Mając do dyspozycji wydajny silnik bazy danych większość zapytań agregujących dane może być realizowana bezpośrednio na hurtowni danych. Jednak jakoś mimo wszystko nadal nie wyobrażamy sobie użytkowników końcowych, zwłaszcza biznesowych posługujących się z zapytaniami TSQL. Właśnie dlatego zdecydowaliśmy się użyć narzędzia jakim jest Power BI. Dzięki możliwości wykorzystania Power BI jako interfejsu dla użytkowników końcowych, wyeliminowaliśmy konieczność posługiwania się zapytaniami TSQL, które zastąpione zostały mechanizmem "Przeciągnij & upuść". Power BI to również doskonałe narzędzie do modelowania danych. Dzięki możliwości wykorzystania języka wyrażeń DAX (Data Analysis Expressions) udało się zbudować dodatkowe miary wyliczalne np. wartości średnie, dynamika sprzedaży czy klasyka analizy, czyli miary typu Month to Date(MTD), Year over Year (YOY), które zapewniają pełną swobodę dostępu dla użytkowników końcowych. Pomimo, że większość operacji wykonywana była czasy odpowiedzi zapytań liczone były w dziesiątkach sekundach. Jednak apetyt rośnie w miarę jedzenia, właśnie dlatego, aby zapewnić jeszcze większą wydajność zdecydowaliśmy się na dodanie dodatkowe komponentu - usługi analitycznej Azure Analysis Services, która jest odzwierciedleniem dobrze znanej z SQL Server usługi Analysis Services w modelu Tabular. Efekt? Dane z hurtowni ładowane są do struktur tabelarycznych Azure Analysis Services, na poziomie AAS uzyskujemy możliwości swobodnego modelowania korzystając również z wyrażeń DAX, a Power BI łączy się do wydajnego silnika, który na zapytania na zbiorze kilkuset milionów rekordów odpowiada w pojedynczych sekundach.

Power BI oprócz samej swobody dostępu do danych gwarantuje dostępność do danych na dowolnym urządzeniu mobilnym, jako, że mobilna aplikacja Power BI dostępna jest na każdym systemie operacyjnym od iOS, przez Android po Windows Phone.

W przypadku bardzo dużych zbiorów danych oraz wydajnej hurtowni (jak w przypadku Azure SQL Datewarehouse), można skorzystać również z opcji Azure Analysis Services w trybie DirectQuery. W jakim celu? Cel jest prosty wydobywać wszystko co najlepsze z Analysis Services czyli swoboda dostępu do użytkownika, mechanizmy bezpieczeństwa na poziomie wierszy z wykorzystaniem DAX, cachowanie i optymalizacja zapytań przez silnik Analysis Services (szczególnie widoczne w najnowszej wersji Analysis Srvices) oraz co w wielu przypadkach najważniejsze - wyeliminowanie konieczności procesowania struktur i danych Analaysis Services.

Efekt końcowy rozwiązania najelpiej obrazu poniższy schemat

Reasumując rosnące zapotrzebowanie w zakresie analizy danych to wyzwanie, wyzwanie, które w zależności od potrzeb i czasu jakim dysponujemy, można zaadresować w ciągu kilku dni, podobnie jak przedstawiliśmy to w Scenariuszu nr 1 lub wykorzystać elastyczność i skalowalność usług analitycznych i hurtowni danych dostępnych na platformie Azure

Autorzy:

Bartłomiej Graczyk
Maciej Stopa

Jak zbudować aplikację w chmurze i nie użyć ani jednego serwera?

mifurm — Mon, 06 Feb 2017 08:00:31 GMT

To, co od zawsze mnie "kręciło" w "chmurach" to wcale nie oszczędności. Dużo potężniejsza jest chmura, gdy doświadczy się jej szybkości i łatwość korzystania z usług, z których można zbudować gotowe rozwiązanie. W świecie biznesu, który pędzi i będzie pędził coraz szybciej, możliwość szybszego zbudowania i wydania aplikacji jest kluczowa i może stanowić o realnej przewadze konkurencyjnej. Podkreślam, może. Jak dla mnie, dopiero wtedy można mówić o niższych, łącznych kosztach dostarczenia całości rozwiązania, a nie poszczególnych komponentów aplikacji. Właśnie w tym kontekście chciałbym przybliżyć Wam proces wykorzystania usług, które razem mogę i dla Was stanowić podstawę architektury Waszej aplikacji. Zanim zacznę - potraktujcie ten wpis jako "spojrzenie z lotu ptaka" na te komponenty, których możecie użyć. Nie wejdziemy tutaj w szczegółowy opis każdego z nich, to zdarzy się w kolejnych wpisach. Nie opiszemy też takich tematów jak skalowanie, monitoring, utrzymanie ciągłości biznesowej czy analiza zdarzeń. Każdy z tych wątków to temat na oddzielny wpis i nie zawsze jeden. Moim celem jest na dziś jest raczej pokazać Wam paletę możliwości, spróbować musicie już sami.

Serwer aplikacyjny

Zacznijmy od góry. Pierwszy element każdej aplikacji to serwer aplikacyjny. Do dyspozycji macie Azure App Service albo Azure App Service Environment. Niezależnie od wyboru możecie pisać aplikację w ASP.NET, Node.js, Java, PHP, czy Python. Można też uruchamiać w ramach tego środowiska skrypty PowerShell czy CMD ale to nie jest ich najistotniejsza wartość. Oba te środowiska w warstwie niższej, niedostępnej dla użytkownika chmury, bazują na serwerze IIS zainstalowanym na maszynach z Windows. Natomiast już pojawiła się wersja App Service obsługiwana przez system Linux. Na dziś w tej wersji możecie skorzystać z gotowych kontenerów (i użyć środowisk PHP, Node.JS czy .Net Core), wybrać inny obraz z Docker Hub bądź swoje prywatne repo. App Service czy App Service Environment to nie wszystkie opcje, możecie pomyśleć o wykorzystaniu Service Fabric czy Azure Container Services, ale te dwa tematy same w sobie wystarczają na wiele kolejnych wpisów na blogu. O różnicach pomiędzy App Service i App Service Environment opowiadałem w czasie spotkania Microsoft Azure User Group. Bardzo robocze slajdy, które służyły tylko jako uzupełnienie, można zobaczyć na docs.com. Najważniejsze wyróżniki omawiane są tu ASE. Z perspektywy architekta proponuję zapamiętać dwa kluczowe elementy: ASE używamy wtedy, gdy potrzebna jest nam duża wydajność oraz duża skala rozwiązania, a także wtedy, gdy chcemy mieć precyzyjny wpływ na ruch sieciowy w naszym środowisku. Dlaczego tak? ASE bowiem zawsze jest uruchamiane w ramach dedykowanego VNET'u i wybranego subnet'u. Wy odpowiadacie za to, jaki ruch wejdzie do serwera aplikacyjnego a jaki nie i to na poziomie sieci. Co więcej, macie gwarancję publicznego stałego, adresu IP lub wielu publicznych adresów i możecie pokusić się o tzw. IP SSL Binding, co pozwala decydować o ruchu sieciowym per opublikowana usługa. Przy dużej ilości niepożądanego ruchu do Waszej strony, możecie go zablokować na warstwie sieci zanim jeszcze on dotrze do serwerów aplikacyjnych. W przypadku App Service jedynym ratunkiem jest wpisanie niepożądanych adresów w Web.config aplikacji, ale wtedy to serwer aplikacyjny blokuje takie połączenia a nie sieć, co zwiększa jego utylizację. Element skalowalności również jest istotny. W ramach Azure App Service maksymalna liczba instancji, jaką możecie wykorzystać to 20, w przypadku ASE jest to 50, w tym dedykowane instancje na Load Balancer, które wstępują w tzw. Front End Pool. W oddzielnym poście postaram się pokazać moje wyniki testów wydajnościowych pomiędzy obiema platformami. Oczywiście nie ma nic za darmo, bazowe środowisko ASE będzie Was kosztowało ok. 1100$ miesięcznie. Takie ASE ma dwie instancje do Load Balancingu (Front End Pool o wielkości P2, nie można ich zmniejszyć) oraz dwie instancje, na których jest aplikacja (Worker Pool 1, o wielkości P1). Co więcej, skalowanie środowiska App Service Enviroment jest dużo wolniejsze niż App Service, ponieważ jest to środowisko dedykowane, pracujące na maszynach, powołanych tylko dla Waszych potrzeb. Oficjalne blogi Microsoft'u powołują się na czas ok. 2 godzin, tyle samo czasu pokazuje portal Azure, efektywnie ostatnio jest to nie więcej niż 45 min. Oznacza to jednak, że proces skalowania nie może być dynamiczny, automatyczny, raczej polega na regułach i okresach, które sami ustalicie. Aktualnie też na ASE nie można wdrażać Azure Functions i nie można wybrać Linux'a jako systemu operacyjnego (obie funkcje są na mapie rozwoju grupy produktowej, co więcej Chris Anderson, który opowiada za Functions i Christina Compy, która odpowiada za ASE są razem w grupie App Service). Poza tym, proces wdrażania rozwiązania, działania oraz monitorowania jest taki sam. Jeśli skala, precyzyjna kontrola ruchu sieciowego czy wydajność nie jest Twoją potrzebą teraz ale również w przyszłości (czy na pewno?), wtedy wybierz App Service. Zmiana decyzji później jest możliwa. Wymaga nieco zaplanowania App Service Planów, zmian w tzw. Publishing Profiles oraz ustawienia App Settings ale poza tym różnic w działaniu samego rozwiązania nie ma. Rozpoczęcie przygody z usługą jest proste i można zacząć ją przechodząc prosty tutorial lub oglądając Kamila Brzezińskiego, który pokazuje jak stworzyć prostą stronę.

Pojemniki na dane

Celowo napisałem pojemniki a nie bazy, bo nie zawsze Wasze rozwiązanie potrzebuje bazy danych. Być może wystarczy składowanie danych w postaci binarnej czy zwykła kolejka. Pomyślcie i o tych rozwiązania, mogą się okazać niezwykle tanie. Jeśli jednak potrzebujecie bazy, to pierwszy dylemat architekta to wybór pomiędzy bazą relacyjną (np. Azure SQL, MySQL) a bazą nierelacyjną, typu NoSQL (np. DocumentDB, MongoDB). Pamiętajcie, że cały czas mówię tylko o usługach dostępnych w PaaS (Platform as a Service). Zakres dostępnych baz jest o wiele szerszy, ale wtedy musimy korzystać z baz instalowanych w ramach maszyn wirtualnych (IaaS). Różnic pomiędzy typami baz jest wiele ale kilka należy podkreślić i zaznaczyć, szczególnie jest dopiero aplikację projektujecie. 1.Jeśli wybierasz bazę NoSQL nie oczekuj, że łatwo zbudujesz w niej relację. Niby oczywiste, bazy NoSQL nie są od tego by projektować w nich relację. O tym jedna zdarza nam się zapominać na etapie projektowania i patrzymy tylko na wygodę zapisywania obiektów typu JSON, brak wymagań co do zawartości obiektów i potencjalnie, łatwe i nieograniczone skalowanie. W jednym z projektów, klient zdecydował na początku, że dane o ofertach sklepu będzie trzymał w DocumentDB. Późniejsze wymagania biznesu jednak wymagały relacji pomiędzy sklepami, ofertami, kupującymi ect. wtedy plusy już nie przysłoniły minusów. Oczywiście budowanie tych relacji na poziomie soft'u nie jest niemożliwe, za to pojawiają się problemy doboru index'u, problem dużych zbiorów, powstałych przez iloczyn kartezjański i inne. Sama baza tych relacji nie zapewnia i developer musi o nie zadbać w procesie CRUD. Postaram się w jednym z postów pokazać podejście do nakładania indexów na bazę DocumentDB, które potrafią dla jednego zapytania zmniejszyć jego koszt ponad 40 krotnie. Więcje o indeksach w tym wpisie. 2.Jeśli w Twojej aplikacji, istotne jest dla Ciebie struktura danych i chcesz, by sam silnik bazy o nią dbał, to wybierz bazę typu SQL. Bazy NoSQL dają Ci wolność, nie musisz zachowywać struktury, nie dotyczą Ciebie żmudne migracje ale właśnie kosztem tego, jest fakt, że o strukturę musisz zadbać sam. Ma to oczywiście potem konsekwencje przy raportowaniu danych z takiej bazy. Jest to możliwe ale ani zakres dostępnych narzędzi ani ich metoda wykorzystania nie są jeszcze bardzo dojrzałe. Niektórzy eksportują dane z baz dokumentowy do silników typu Hadoop i tam budują raporty. Drugim elementem, związanym z schematem są funkcje agregujące. Na teraz ich zestaw jest nieco ograniczony, można pisać własne za pomocą JavaScript, ale nie skalują się jeszcze idealnie. Jeśli ktoś z Was będzie miał tutaj wyzwania, pomogę. Dwie ważne referencje: raporty w PowerBI dla DocumentDB, funkcje agregujące w DocumentDB. 3. Piszesz "grę dla całego świata" i potrzebujesz silnika danych, który ją będzie wspierał? Bazy dokumentowe z reguły łatwiej dzielić na małe kawałki i skalować. Warto poczytać o metodzie "partycjonowania" czy "sharding'u" dla Document DB oraz dla Azure SQL. Sam "sharding" nie jest domeną tylko baz NoSQL ale skalowanie i działanie w ramach wielu regionów świata już tak. Co więcej, dla baz typu DocumentDB, jest to praktycznie jedyny model osiągania dużej skali, więc wybierając taką bazą od razu planuj jak korzystać z shardów. Pojedyncza kolekcja DocumentDB bez shardów portafi dostarczyć maksymalnie 10 000 RU/s. Jeśli nadal po przeczytaniu tych różnic nie wiesz, co wybrać, generalna reguła mogłaby być taka. Jeśli Twoje dane, które będziesz przechowywał w aplikacji, silnie od siebie zależą a co więcej, nie piszesz aplikacji dla "całego świata" i nie umiesz wyobrazić sobie architektury z wieloma niewielkimi bazami danych, najprawdopodobniej baza typu Azure SQL jest dla Ciebie. Jeśli jednak, przechowywane dane są mocno niezależne, mogą szybko zmieniać swoją strukturę (budujesz drugiego Twittera lub Facebook'a albo grę), będzie mógł łatwo wprowadzić koncepcję, jedna kolekcji danych per klient czy grupa klientów, to wtedy raczej szukasz bazy dokumentowej.

"Who is who" czyli co zrobić z tożsamością

Jeśli już uporaliśmy się z wyborem serwera aplikacyjnego, środowiska, języka, i wiecie, gdzie będziecie trzymać dane, to przyszedł czas na kolejny, kluczowy do rozstrzygnięcia element. Gdzie i jak będziesz przechowywał użytkowników swojej aplikacji, nimi zarządzał i jakie możliwości samoobsługi zaproponujesz. I tu wybór jest ciekawy. Co mamy w menu: 1) Azure Active Directory 2) Azure Active Directory Services 3) Azure Active Directory B2C 4) Azure Active Directory B2B 5) Usługa Active Directory na Azure VM A mówią, że od przybytku głowa nie boli a tu nagle pojawia się 5 sposobów na przechowywanie tożsamości użytkownika. Prawdą jest, że każda ma nieco inne przeznaczenia i postaram się je tutaj omówić. Jeśli Wasza aplikacja nie powstała w chmurze, swój żywot poczęła w lokalnych DC i korzystała standardowego Active Directory, to teraz w świecie chmury, może nadal korzystać z tego typu katalogu. Taka aplikacja rozumie Windows Authenticaion ale już nie koniecznie wie czym jest OAuth2.0. Wtedy przyda Wam się standardowy katalog zainstalowany na maszynie wirtualnej, patrz pkt. 5. Jedną z takich aplikacji jest np. SharePoint 2013. Co prawda, może równie dobrze pracować z Azure AD dzięki dodatkowemu komponentowi ale jednak pełen katalog jest jego naturalnym przeznaczaniem. Co więc zrobić maszynami wirtualnym w Azure, do których dostęp powinny mieć osoby tylko z katalogu Azure AD? Czy można nie korzystać z kont lokalnych? Z pomocą przychodzi pkt. 2 czyli usługa Domain Services, która w wybranych przez Was VNET'ach pozwoli Wam podłączyć maszyny do Azure AD. Otrzymacie usługi katalogowe zgodne z LDAP i możliwości wykorzystania Kerberosa. Efektywnie chmura w danym VNET rezerwuje sobie pewien zakres adresów i wdroży maszynę wirtualną, do której użytkownik usługi nie ma żadnego dostępu i za działanie usługi odpowiada Microsoft. Co innego, jeśli Wasza aplikacja powstaje w chmurze i będzie prezentowana w Internecie, wtedy naturalnym miejsce składowania tożsamości jest Azure Active Directory, które z tradycyjnym Active Directory ma wspólną nazwę. Jest to katalog użytkowników, grup ale też kont usługowych, przeznaczonych do wykonywania konkretnych czynności w Azure (Azure Automation). Nie jest to miejsce na składowanie polityk, wszystkich komputerów czy drukarek. Azure Active Directory jest katalogiem skierowanym na użytkownika aplikacji. Dokładnie o możliwościach, które są nie małe, postara się napisać Piotr Boniński w innym poście. I teraz dochodzimy do dwóch odmian Azure AD czyli B2C oraz B2B. Różnica między nimi jest zasadnicza i można ją sprowadzić do stwierdzenia: jeśli wszyscy użytkownicy, korzystający z Twojej aplikacji w chmurze znajdują się w Twoim katalogu i nie robisz integracji z kontami sieci społecznościowych, to wtedy odmiany B2C czy B2B w ogóle Cię nie interesują. Jeśli jednak chcesz pozwolić użytkownikowi na zakładanie konta i logowanie się jego tożsamością z LinkedIn, Facebook, Google czy Amazon wtedy Azure AD B2C jest Twoim przyjacielem. Tak naprawdę Azure AD B2C jest swego rodzaju proxy, Twoja aplikacja integruje się tylko z B2C, a B2C już martwi się oto, jak tożsamość z innego katalogu, traktować w jeden i ten sam sposób. I to jest chyba największa zaleta katalogu, że integracja jest po stronie dostawcy. Możesz napisać też własnego dostawcę tożsamości (custom IdP) i zintegrować aplikację biznesową. Co więcej B2C dzięki tzw. politykom (singin, signup policy) daje wiele gotowych ekranów od razu, takich jak choćby ekran utworzenia konta, logowania czy resetu hasła. Na dziś te ekrany można w dużej mierze dostosowywać poprzez elementy graficzne oraz CSS, w przyszłości pojawi się też JavaScript. Są też biblioteki na platformy mobilne, iOS oraz Android, co pozwala na natywną integrację aplikacji mobilnej. B2C załatwia jeszcze jeden, bardzo istotny a chętnie pomijany przez twórców aplikacji element. B2C jest gotową i dobrą implementacją OAuth2.0 oraz OpenID. I jest to bardzo istotne jeśli zależy nam na branżowym standardzie zaimplementowanym w bezpieczny sposób, który np. dba o wymianę i odświeżanie tokenów czy utworzenie nowego tokena, jeśli poprzedni wygasł. Implementacja integracji z każdym z tych dostawców tożsamości wcale nie jest trywialną zabawą, jeśli chcieć to pisać samemu. O Azure AD B2C mówiłem w trakcie spotkania Microsoft Azure User Group. Temu rozwiązaniu też przyda się oddzielny wpis, pokazujący co i jak warto wykorzystać na bazie dwóch moich wdrożeń. Pierwszy tips&trick o B2C pojawił się na moim blogu. Będzie ich więcej. I na koniec zostało B2B, które tak naprawdę nie jest innym typem katalogu. Jeśli zależy Ci na wykorzystaniu tożsamości z różnych katalogów Azure AD aby przyznawać dostęp do aplikacji to rozwiązanie B2B może okazać się dla Ciebie. Nie mam praktycznych doświadczeń z wykorzystaniem tego, więc znowu poproszę Piotra Bonińskiego, by ten świat nam przybliżył. Wybaczcie długość. Przy następnym wpisie postanawiam poprawę! Będziemy kontynuować wątek usług PaaS.