Traffic Manager, Externí a Interní load balancer

V rámci Microsoft Azure, existuje mnoho částí/komponent IaaS (Infrastructure as a Service) infrastruktury, které poskytují zajímavou funkcionalitu z hlediska nasazení širokého spektra různých aplikací. V tomto článku se budeme postupně zabývat nasazením Externího Load Balancingu, Interního Load balancingu a Traffic Managera. S tím, že nakonec společně skombinujeme Externí Load Balancing s Traffic Managerem. Všechny tyto „komponenty“ pak souvisejí se síťovou částí IaaS. Vysvětlení pojmů: (Poznámka: Postupy jsou platné pro virtuální stroje první generace)


VIP: V případě, že vytváříme v rámci IaaS virtuální stroj, pak z hlediska nastavení síťové části vytvářeného virtuálního stroje můžeme rovnou v průvodci definovat tzv. VIP IP adresu a to buďDynamickou, neboRezervovanou. V případě VIP se jedná o veřejnou (“internetovou”) IP adresu z rozsahu veřejných IP adres ve vlastnictví společnosti Microsoft. Přičemž výchozí volbou je Dynamická VIP. To tedy znamená, že tato veřejná IP adresa není přidělena natrvalo a může se změnit! Například pokud vypnete virtuální stroj do stavu „Stopped (deallocated)“ (tedy standardní způsob vypnutí) dojde k dealokování všech zdrojů, které v tu danou chvíli virtuální stroj spotřebovává a to včetně dealokování VIP IP Adresy. Pokud posléze virtuální stoj zapnete, je zde velká pravděpodobnost, že se VIP IP adresa změní. Což představuje komplikaci např. v případě, pokud jste přesměrovaly záznamy z vaší veřejné DNS zóny na tuto VIP IP adresu. Kupříkladu pokud jste záznam typu „A“ www.strankymojefirmy.cz přesměrovaly na tuto VIP. V případě, že vybereme volbu „Reserved“, dochází k rezervování dané veřejné IP adresy „napořád“. Aktuální výchozí limit pro konkrétní subskripci je pak 20 rezervovaných VIP IP adres. Dále je třeba upozornit na to, že si nelze rezervovat konkrétní veřejnou IP adresu. Vždy v případě rezervace veřejné IP adresy dojde k přidělení náhodné volné veřejné IP adresy, ale opravdu natrvalo. Také je třeba říci, že VIP IP adresa, i když se zadává při vytváření virtuálního stroje, je ve skutečnostech navázána naCloud Service*****. Cloud Service si lze představit jako jakýsi kontejner, ve kterém se nachází jeden a více virtuálních strojů. Zde je pak ceník veřejných VIP IP adres: https://azure.microsoft.com/cs-cz/pricing/details/ip-addresses/

Jednoduché schéma asociované VIP IP adresy Příklad rezervace VIP IP adresy pomocí PowerShellu $reservedIP = New-AzureReservedIP -ReservedIPName "Moje nova VIP" -Label "NovaVIP" -Location "West Europe" Tedy na tomto příkladu jsem provedl vytvoření rezervace veřejné VIP IP adresy s označením „Moje nová VIP“ a to v lokalitě Západní Evropa. V tomto příkladu pak za jednotlivé proměnné dosadíme hodnoty, přičemž nás zajímá v tuto chvíli parametr „–ReservedIPName”, který říká, že při vytváření virtuálního stroje bude použita toto konkrétní rezervovaná VIP. New-AzureVM -ServiceName $serviceName -VNetName $vnetname -VMs $vm1 -ReservedIPName $reservedIP -Location $location ***… To se týká ovšem jen virtuálních strojů první generace. U virtuálních strojů druhé generace je to jinak!


DIP: Jedná se o interní IP adresu související s danou vNET. Platí, že při vytváření virtuálního stroje je vhodné definovat interní síť tzv. vNET. Součástí vNET je i definice samotných subnetů. Pak v daném subnetu je „umístěn“ virtuální stroj a z daného subnetu pak získá interní IP adresu. IP adresu lze v tomto případě získat dvěma způsoby. Získáním IP adresy z DHCP serveru, který běží skrytý na pozadí a který není možné spravovat. Pak ale může nastat situace, že po opětovném spuštění virtuální ho stroje získá virtuální stroj jinou DIP. Což se například nehodí v případě, kdy v Azure běží doménový řadič (Active Directory) a zároveň je zde instalována služba DNS, na kterou se odkazují kvůli překladu interních DNS zón jiné virtuální stoje (dns klienti). Nebo druhá metoda „Static“, resp. pseudo static, kdy je IP adresa sice stále přidělována z DHCP serveru, ale formou rezervace dané IP adresy. Je důležité říci, že je možné rezervovat interní IP adresu v daném subnetu až od IP adresy „xxx.xxx.xxx.4”. IP adresy xxx.xxx.xxx.1 až xxx.xxx.xxx.3 jsou rezervovány pro interní účely. Samozřejmě při vytváření interní Azure sítě vNET je možné sítě definovat pouze z rozsahů definovaných dle RFC. A není možné interně definovat síť z veřejného rozsahu IP adres.


**


Jednoduché schéma asociované DIP IP adresy Příklad rychlého vytvoření virtuálního stroje, kde v tomto případě nás zajímá přepínač „Set-AzureStaticVNetIP -IPAddress 10.0.0.10“. Na tomto příkladu je vytvořen virtuální stroj v síti „TestVnet“, zařazen do subnetu „Subnet-1“ a dostane přidělenu preudo statickou interní IP adresu „10.0.0.10“. New-AzureService -ServiceName TestService -Location “West Europe” $image = Get-AzureVMImage|?{$_.ImageName -like “RightImage-Windows-2012R2-x64”} New-AzureVMConfig -Name TestVM -InstanceSize Small -ImageName $image.ImageName </font> <font color="#0000ff">| Add-AzureProvisioningConfig -Windows -AdminUsername adminuser -Password P@ssw0rd123</font> <font color="#0000ff">| Set-AzureSubnet –SubnetNames Subnet-1 | Set-AzureStaticVNetIP -IPAddress 10.0.0.10 ` | New-AzureVM -ServiceName “TestService” –VNetName TestVnet


EndPoint: V případě VIP, je nutné navíc definovat pro daný virtuální stroj tzv. EndPoint. Neboli definici interního portu a externího portu, na který bude komunikace směrována, a která přichází na danou VIP. Přičemž externí i interní port nemusí být stejný. Tedy například externí port může být TCP 80, ale interní port, na kterém například na virtuálním stroji poslouchá webová služba TCP 8080. Dále platí, že v případě, že existují v Cloud Service dva a více virtuální stroje, nemohou být tyto definice portů duplicitní. Tedy převedeno do praxe. Pokud je definován pro jeden virtuální stroj (Linux) SSH EndPoint na standardním externím portu TCP 22 a interním portu rovněž TCP 22, další stoj v Cloud Service nemůže použít tyto již obsazené porty, a to jak pro interní, tak pro externí definici portů.


**


Jednoduché schéma definice EndPointů****


Příklad přidání SSH endpointu pro daný virtuální stroj v PowerShellu $prot = "tcp" $localport = 22 $pubport = 22 $endpointname = "SSH Daemon" Get-AzureVM -Name $vmname -ServiceName $serviceName | Set-AzureEndpoint -Name $endpointname -Protocol $prot -LocalPort $localport -PublicPort $pubport | Update-AzureVM



Definice prostředí: V tomto článku použiju již vytvořené existující virtuální stoje viz. obrázek a tabulka níže.

 

**Název VM** **Veřejné DNS jméno** **Interní IP Adresa** **Operační systém**
susewesteu1 susewesteu.cloudapp.net**** 192.168.150.50 SUSE LINUX
susewesteu2 susewesteu.cloudapp.net 192.168.150.51 SUSE LINUX
susewestus1 susewestus.cloudapp.net 192.168.152.50 SUSE LINUX
Susewestus2 susewestu**s**.cloudapp.net 192.168.152.51 SUSE LINUX
wrksusewesteu**** wrksusewesteu.cloudapp.net**** 192.168.150.11 SUSE LINUX
wrksusewestus**** wrksusewestus.cloudapp.net**** 192.168.152.11 SUSE LINUX
wrkswesteu**** wrkswesteu.cloudapp.net**** 192.168.150.10 WINDOWS
wrkswestus**** wrkswestus.cloudapp.net**** 192.168.152.10 WINDOWS

External Load Balancer Co je externí load balancer? Jedná se o možnost vyvažovat/balancovat komunikaci na určitém externím portu a to na více jak jeden virtuální stroj. Tedy typickým příkladem je webová služba běžící na dvou a více virtuálních strojích a je zde potřeba tuto komunikaci, například na portu TCP 80 distribuovat na dva a více těchto webových serverů. Opět typickým důvodem je snaha vyřešit vysokou dostupnost webové služby. Pokud jeden ze serverů bude mít problém, komunikace je přesměrována automaticky na druhý server. Tedy Externí Load Balancer lze využít nejen pro případ Load Blancingu, ale také pro případ Failoveru.

Jednoduché schéma zapojení Externího load balanceru Poznámka: Veškeré nastavení se děje skrze grafickou webovou konzoli pro zprávu Microsoft Azure a to na adrese – https://portal.azure.com** Přistoupíme tedy samotné praktické implementaci Externího Load Balanceru. Na obrázku vidíme v tomto případě vytvoření samotného virtuálního strojeprvní generace (Classic) „susewestus1“. Kde virtuálnímu stroji definuji rezervovanou VIP a presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do virtuální sítě „susewestus“ a do subnetu „westus**“ s rozsahem interních IP adres 192.168.152.4-192.168.152.254.

Zde pak zařazení virtuálního stroje do správného storage accountu. A což je důležitější, je zde ukázáno, že skutečně je virtuální stroj vytvořen v lokalitě West US.

Na obrázku vidíme v tomto případě vytvoření samotného virtuálního strojeprvní generace (Classic) „susewestus2“. Kde u virtuálnímu stroje použiji již existujícístejnou rezervovanou VIP a jinou presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do stejné virtuální sítě „susewestus“ a do stejného subnetu „westus“ s rozsahem interních IP adres 192.168.152.4-192.168.152.254.

Ve stejném duchu opět na obrázku vidíme vytvoření samotného virtuálního stroje první generace (Classic) „susewesteu1“. Kde virtuálnímu stroji definuji rezervovanou VIP a presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do virtuální sítě „susewesteu“ a do subnetu „westeu“ s rozsahem interních IP adres 192.168.150.4-192.168.150.254.

A opět na obrázku vidíme vytvoření samotného virtuálního strojeprvní generace (Classic) „susewesteu2“. Kde u virtuálního stroje použiji již existujícístejnou rezervovanou VIP a jinou presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do stejné virtuální sítě „susewesteu“ a do subnetu „westeu“ s rozsahem interních IP adres 192.168.150.4-192.168.150.254.

Nyní, když už máme vytvořeny všechny čtyři virtuální stroje, je možné přistoupit k vytvoření a nastavení samotného Externího Load Balanceru. Tedy v rámci nastavení již existujícího virtuálního stroje klikneme na volbu „Load balanced sets“ a klikneme na tlačítko „Join“. Dále si vybíráme mezi meziPublic/Veřejným Load Balancerem aInternal/Interním Load Balancerem. Následně je nutné definovat parametry nastavení samotného Load Balanced setu a kliknout na volbu „Load balanced set“. Zde navíc nastavuje interní port, na kterém budou poslouchat virtuální stroje a to „Private port“.

Zde již vidíme samotné parametry, které lze nastavit. Jednak Load balanced set pojmenujeme. V ném případě „HTTP“. A dále vydefinujemePublic/Veřejný port,Probe protocol,Probe port. Zbylé nastavení můžeme ponechat nezměněno. Přičemž „Probe“ je „sonda“, která zjišťuje, zda jsou jednotlivé koncové body (virtuální stroje) stále dostupné. V případě, že sonda zjistí, že některý z koncových bodů není dostupný, automaticky komunikaci přesměruje na koncové body, které jsou aktuálně dostupné.

Na obrázku pak vidíte dva již vytvořené Load Balanced sety a to pro porty TCP 80 a TCP 443 a to pro virtuální stroj „susewesteu1“.

V případě dalšího virtuálního stroje, v tomto případě „susewesteu2“ stačí jen daný virtuální stroj zařadit do stejného Load balanced setu. Jak je vidět při dokončení vytváření Load balancing setu je možné definovat „Private/Privátní“ Port. To tedy znamená, že komunikace bude přicházet například na port TCP 80, ale bude interně na virtuální port přeměřována například na port TCP 81. Tedy platí, že „Public port“ a „Private Port“ nemusí být stejné.

Výsledek přidání virtuálního stroje „susewesteu2“ do společných Load balanced setů

Stejným způsobem pak vytvoříme load balanced set pro virtuální stroj „susewestus1“ a do tohoto load lanaced setu zařadíme rovněž virtuální stroj „susewesteu2“

Příklad vytvoření Externího Load balancingu pomocí PowerShellu. Platí, že ve společném Cloud Service musí existovat minimálně dva virtuální stroje, aby to mělo význam. A toto platí jen pro virtuální stroje první generace. Get-AzureVM -ServiceName "wrksusewestus" -Name "wrksusewestus" | Add-AzureEndpoint -Name "HTTPS" -Protocol "TCP" -PublicPort 443 -LocalPort 443 -LBSetName "Web-Farm" -DefaultProbe | Update-AzureVM



Internal Load balancer Interní Load Balancer funguje na stejném principu jako Externí load balancer. S tím rozdílem, že cílem je balancovat porty ne na veřejné IP adrese, ale na specifické interní IP adrese. Opět z hlediska praktického použití. Představte si situaci, kdy máte „více vrstvou/multi-tier“ aplikaci, kde webové servery mají nastaven External Load balanced set a interní aplikační servery mají nastavený interní load balanced set.

Jednoduché schéma zapojení Interního load balanceru A opět postup přidání virtuálního serveru „susewestus1“ do interního load balanced setu což je takřka totožné jako v případě externího load balanced setu. Nejprve vybereme, že chceme vytvořit „Internal“ load balanced set a dále definuji název pro EndPoint a privátní port na kterém bude load balancing probíhat. V mém případě interní port TCP 8080. Dále je třeba nastavit zbylé parametry kliknutím na volbu „Load balanced set“.

Zde pak definujeme v jaké sítí a na jaké interní IP adrese bude load balancer naslouchat. V mém případě na IP adrese 192.168.152.100. Přičemž veřejný port, tedy TCP 8080 je stejný jako definovaný interní port.

Zde již vidíte v seznamu Load balanced setů nově vytvořený Internal load balanced set.

A opět stejný postup v případě dalších virtuálních strojů, které mají být součástí interního load balaced setu. Tento další virtuální stroj stačí přidat do již existujícího.

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewestus2“

Příklad vytvoření Internal Load Balanceru v PowerShellu Načtení informací o virtuálním stroji do proměnné $vm1 = Get-AzureVM -ServiceName wrksusewestus -Name wrksusewestus Přidání interního load balanceru k již existujícímu virtuálnímu stroji Add-AzureInternalLoadBalancer -ServiceName wrksusewestus -InternalLoadBalancerName "App01ILB" -SubnetName "westus" -StaticVNetIPAddress "192.168.152.200" Přidání Ednpointu $vm1 | Add-AzureEndpoint -Name "WEB" -Protocol tcp -LocalPort 80 </font> -<font color="#0000ff">PublicPort 80 -LBSetName &quot;weblbset&quot; -InternalLoadBalancerName "App01ILB" ` -DefaultProbe Update konfigurace virtuálního stroje $vm1 | Update-AzureVM Příklad odstranění EndPointu $vm1 | Remove-AzureEndpoint -Name HTTP Testování: Na virtuálních stojích „susewestus1“ a „susewestus2“ již běží webový server APACHE. Ten je nastaven tak, že poslouchá na portu TCP 80 pro externí komunikaci a dále poslouchá na portu TCP 8080 pro interní komunikaci na síťi 192.168.152.0/24 Přihlásil jsem se na virtuální stoj „wrksusewestus“ který je rovněž zařazen do sítě 192.168.152.0/24. A zde spustil Firefox. Do pole pro zadání URL adresy jsem zadal http://192.168.152.100:8080, tedy IP adresu, na které poslouchá interní load balancer. Jak je z obrázku patrné, zobrazila se mi jednoduchá webová stránka. Pokud jsem pak provedl „refresh“ stránky, došlo k zobrazení této stránky jednou z virtuálního serveru „susewestus1“ a jednou z „susewestus2“. Tedy výsledkem je, že interní load balancer úspěšně funguje.

Pokračujeme tedy v nastavení interního load balanceru na virtuálních strojích v lokalitě WEST EUROPE. Níže pak vidíte postup při přidání virtuálního serveru „susewesteu1“ do interního load balanced setu. Nejprve vybereme, že chceme vytvořit „Internal“ load balanced set a dále definuji název pro EndPoint a tentokrát privátní port na kterém bude load balancing probíhat. V mém případě interní port TCP 8080. Dále je třeba nastavit zbylé parametry kliknutím na volbu „Load balanced set“. Zde pak definujeme v jaké sítí a na jaké interní IP adrese bude load balancer naslouchat. V mém případě na IP adrese 192.168.150.100. Přičemž veřejný port, tedy TCP 8080 je stejný jako definovaný interní port.

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewesteu1“

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewesteu2“




Testování: Na virtuálních stojích „susewesteu1“ a „susewesteu2“ již běží webový server APACHE. Ten je nastaven tak, že poslouchá na portu TCP 80 pro externí komunikaci a dále poslouchá na portu TCP 8080 pro interní komunikaci na síťi 192.168.150.0/24 Přihlásil jsem se na virtuální stoj „wrksusewestus“ který je rovněž zařazen do sítě 192.168.152.0/24. A zde spustil Firefox. Do pole pro zadání URL adresy jsem zadal http://192.168.150.100:8080, tedy IP adresu, na které poslouchá interní load balancer. Jak je z obrázku patrné, zobrazila se mi jednoduchá webová stránka. Pokud jsem pak provedl „refresh“ stránky, došlo k zobrazení této stránky jednou z virtuálního serveru „susewestus1“ a jednou z „susewestus2“. Tedy výsledkem je, že interní load balancer úspěšně funguje.

Příklad z praxe: **

Jednoduché schéma ukázky implementace 3 tierové aplikace Se souhlasem společnostiE.ON Česká republika, s.r.o. , zde uvádím příklad praktické implementace 3 tierové aplikace v Microsoft Azure za pomocí Interního i Externího load balancingu a běžící kompletně na Linuxovém operačním systému.

**



Traffic Manager Traffic manager neprovádí například Traffic shaping, jak by se dalo i z jeho názvu očekávat, ale provádí globální a to slovo je opravdu velmi důležité, globální směrování určitého síťového provozu. Představme si situaci, kdy potřebujeme mít například dostupné webové stránky, nebo určitou aplikaci a to i v případě, že dojde ke kompletnímu selhání jednoho z datacenter firmy Microsoft. A bohužel to bude zrovna datacentrum, kde nám jako firmě běží naše kritické aplikace, nebo webové služby. A právě Traffic Manager slouží mimo jiné pro účely přesměrování síťového provozu i v těchto případech. Později pak popíšu, že metod jak lze provoz směrovat je více. Na obrázku níže je pak obecné schéma, na jakém je znázorněn princip fungování Traffic Managera. Zde v kombinaci s metodou přesměrování na základě času odezvy. Tedy klient (dns klient) se doptá svého DNS serveru, ať mu vrátí název suseexperdays.trafficmanager.net. Nebo lépe v praxi si představte situaci, kdy z vašeho lokálního DNS serveru (např. u poskytovatele připojení, nebo tam kde dns zónu hostujete) je nastaven záznam typu ALIAS ve formátu www.mojefiremnistranka.cz, mířící na DNS záznam suseexperdays.trafficmanager.net. Lokální DNS server se zeptá Traffic Managera a ten provede vyhodnocení celé situace a to na základě zvolené metody směrování síťového provozu a na základě dostupnosti jednotlivých koncových bodů (virtuálních strojů). Následně lokálnímu DNS serveru vrátí informaci s plným názvem Cloud Service (jen v případě virtuálních strojů první generace). Na obrátku je vidět, že klient se nachází v lokalitě WEST US. A zvolená metoda je na základě času odezvy. Proto Traffic Manager vrátí název Cloud Service odpovídající lokalitě/datovému centru firmy Microsoft - WEST US. Klient se pak následně napřímo pokusí spojit, v našem případě zobrazit webovou stránku. **



Zde je pak ukázka jednotlivých webových stránek, tak jak se zobrazují. Každý server v každé lokalitě je zobrazen jak jinou barvou, tak je zobrazen název webového serveru, ze kterého jsou aktuálně stránky zobrazeny.

Vytvoření Traffic Managera: V portálu klikněte na „+ New“, a vyberte „Networking“ – „Traffic Manager profile

Zde zadáme název budoucího Traffic Managera. Výsledné DNS jméno pak bude<name>.trafficmanager.net. Dále vybereme routovací metodu. Máme na výběr ze tří možností. „Performace“ – tato metoda zaručuje, že Traffic Manager na pozadí provádí měření dostupnosti jednotlivých Endpointů. Tedy měření rychlosti odezvy v milisekundách a udržuje si tabulku s naměřenými hodnotami. Rovněž si udržuje tabulku odezvy pro různé „siťové body“ po celém světě. Pokud zjistí, že klient, tedy jeho DNS požadavek přišel z určité sítě, porovná tabulky s odezvami a vrátí klientovy, resp. jeho lokálnímu DNS serveru název Cloud Service z lokality s nejmenší odezvou vůči jeho lokálnímu DNS serveru. „Weighted“ – tato metoda využívá principu Round Robin. Tedy Traffic Manager se pokouší rovnoměrně vyvažovat routování komunikace, tak aby se jednotlivé Endpointy neustále střídaly a to bez ohledu na dobu odezvy apod. „Priority“ – toto metoda využívá principu Failover, tedy Traffic Manager nabízí nejprve Endpointy s nastavenou vysokou prioritou a jen v případě, „selhání/nedostupnosti“ Endpointu s vysokou prioritou, je až poté nabídnut Endpoint z nižší prioritou. My vybereme metodu „Performance“.

Zde pak naleznete detailní popis jednotlivých routovacích metod https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-routing-methods/ Po vytvoření Traffic Managera je nutné přidat samotné Endpointy. Tedy klikneme na „All settings

Zde pak klikneme na volbu „Endpoints“ a dále klikneme na tlačítko „+ Add

Při definici samotného Endpointu máme rovněž na výběr z několika možností. Buď se může jednat o Endpoint v samotném Microsoft Azure, nebo se může jednat o externí Endpoint. My vybereme volbu „Azure endpoint“. Dále je zde možnost vybrat „Target resource type“. Máme na výběr buď „Cloud Service“ – pro virtuální stroje první generace, nebo „App Service“ – což jsou například samostatné webové, nebo aplikační servery. Typicky spravované pomocí Visual Studia. A nakonec „Public IP address“ – slouží pro přidání Endpointů souvisejících s virtuálními stroji druhé generace. V našem případě vybereme volbu „Cloud Service“

Následně klikneme na volbu „Target resource“ a je nám nabídnut seznam všech Cloud Service.

My přidáme Cloud Service s názvem „susewesteu“ a „susewestus“ a stejně tak pojmenujeme i nově vytvořené Endpointy.

Zde pak vidíme již přidané Endpointy.

Příklad vytvoření Traffic Manager profile pomocí PowerShellu. $profile = New-AzureRmTrafficManagerProfile –Name TM01 -ResourceGroupName "Group-1" -TrafficRoutingMethod Performance -RelativeDnsName tm01 -Ttl 30 -MonitorProtocol TCP -MonitorPort 80 -MonitorPath "/" Identifikace klasického Cloud Service, který chceme přidat jako Endpoint a uložení do proměnné $cloudService = Get-AzureRmResource -ResourceName susewesteu -ResourceType "Microsoft.ClassicCompute/domainNames" -ResourceGroupName "Group-1" Přidání samotného Endpointu do profilu Traffic Managera New-AzureRmTrafficManagerEndpoint –Name susewesteu –ProfileName TM01 -ResourceGroupName "Group-1" –Type AzureEndpoints -TargetResourceId $cloudService.ResourceId –EndpointStatus Enabled Testování: Přihlásil jsem se na testovací stanici „wrksusewesteu“

Zde v prohlížeči Firefox jsem zadal jako URL adresu: http://mylocation.org. Služba správně určila, že přístupový „internetový“ bod, ze kterého se připojuji je městoAmsterdam, tedy WEST EUROPE datové centrum firmy Microsoft.

Dále jsem do prohlížeče, resp. URL adresy zadal název mého Traffic Managera. Tedy http://suseexpertdays.trafficmanager.net. Jak je patrné díky zvolené metodě „Performance“ se mi zobrazila webová stránka nacházející se na webovém serveru v lokalitě WEST EUROPE.

Přihlásil jsem se na testovací stanici „wrksusewestus“

Zde v prohlížeči Firefox jsem zadal jako URL adresu: http://mylocation.org. Služba správně určila, že přístupový „internetový“ bod, ze kterého se připojuji je městoSan Francisco, tedy WEST US datové centrum firmy Microsoft.

Dále jsem do prohlížeče, resp. URL adresy zadal název mého Traffic Managera. Tedy http://suseexpertdays.trafficmanager.net. Jak je patrné díky zvolené metodě „Performance“ se mi zobrazila webová stránka nacházející se na webovém serveru v lokalitě WEST US.

Následně jsem provedl změnu metody routování z „Performance“ na „Weighted“

Dále jsem v prohlížeči do adresy URL opětovně zadal http://suseexpertdays.trafficmanager.net. Tentokrát se po vynuceném „refresh“ stránky zobrazují střídavě webové stránky ze všech webových serverů a to z obou lokalit.

Poznámka: V případě, pokud by stránky správně nefesreshovaly, je zde možnost jak situaci případně vyřešit. A to pustit v Linuxu konzoli a pomocí příkazu „sudo rcnscd restart“ situaci vyřešit.


Užitečné odkazy: https://azure.microsoft.com/en-us/services/traffic-manager/ https://azure.microsoft.com/cs-cz/documentation/articles/traffic-manager-powershell-arm/ https://azure.microsoft.com/cs-cz/documentation/articles/load-balancer-get-started-internet-arm-ps/ https://azure.microsoft.com/cs-cz/documentation/articles/virtual-machines-load-balance/

Autor: Jakub Heinz

Next Post Previous Post