În acest articol vom analiza cele mai importante servicii care ne ajută să creăm o reţea mai bună pe infrastructura Azure. Presupun că deja cunoaşteţi conceptele de bază din cloud.
Cele trei servicii care intră în această categorie sunt:
Vom analliza fiecare serviciu separat.
Traffic Manager ne permite să distribuim traficul către diferite endpoints. Acestea pot fi pe centre de date diferite. Din anumite perspective putem privi Traffic Manager-ul ca pe un Load Balancer la nivel global. În acest fel putem instala o soluţie pe centre de date multiple şi putem redirecţiona traficul în funcţie de locaţia utilizatorului.
Traffic Manager verifică starea endpoint-ului la anumite intervale de timp. Dacă de patru ori la rând endpoint-ul este oprit, endpoint-ul va fi marcat drept oprit, iar traficul nu va mai fi redirecţionat către acel endpoint. Utilizatorii care ştiu deja despre acel endpoint, vor mai încerca să se conecteze la acel endpoint până când DNS cache expiră (DNSTTL).
Traffic Manager este utilizat numai pentru a rezolva adresa endpoint. Odată ce endpoint-ul este rezolvat, cererea va merge direct către endpoint şi nu va trece prin managerul de trafic.
Fiecare instanţă Traffic Manager va avea propriul său nume DNS. Noi vom înregistra acest DNS în spatele DNS-ului nostru real dacă dorim să redirecţionăm traficul de la site-ul nostru (www.foo.com) prin Traffic Manager.
Îl putem configura folosind Power Shell, REST API sau Management Portal. Toate caracteristicile sunt disponibile din fiecare instrument.
Putem specifica cât timp va fi depozitat numele DNS rezolvat de Traffic Manager de către clienţii noştri.
Există trei tipuri de echilibrare a volumului de date suportate în acest moment:
Performanţa – Pe baza performanţei şi a volumului fiecărui endpoint (bazată pe latenţă);
Round Robin – Traficul este redirecţionat către toate endpoint-urile într-un mod echilibrat (prima cerere merge către endpoint 1, a doua către endpoint 2 şi aşa mai departe);
Failover (Reluare în caz de nereuşită) – Atunci când primul endpoint este oprit, traficul este redirecţionat către al doilea endpoint (şi aşa mai departe). Noi putem specifica ordinea reluării.
Fiecare endpoint poate avea o încărcătură specifică care va fi utilizată de către Traffic Manager pentru distribuţia traficului. Valori mai mari înseamnă că acel endpoint poate primi mai mult trafic. Acesta este utilizat de metodele de echilibrare date Round Robin (acesta poate fi configurat numai din PowerShell sau REST API).
Traffic Manager ne permite să specificăm ce endpoint să monitorizăm. Putem utiliza endpoint-uri HTTP/HTTPS. Putem de asemenea specifica un port sau o cale la comandă. Pentru toate punctele finale va fi utilizat acelaşi endpoint monitor.
Un profil Traffic Manager reprezintă toată configuraţia pentru un nod specific.
Traffic Manager ne permite să specificăm un alt punct final de trafic. În acest fel, noi putem defini profiluri complexe de reluare şi putem gestiona diferite reguli de echilibrare a volumului de date.
Traffic Manager poate fi utilizat de către propriul tău DNS de domeniu. DNS-ul tău trebuie să indice DNS TRaffic Manager.
Toate endpoint-urile trebuie să fie din aceeaşi subscripţie. Nu poate fi utilizat cu endpoint-uri externe.
Utilizatorii vor fi redirecţionaţi către endpoint-ul cel mai apropiat. În acest fel, clienţii pot ajunge la endpoint-ul care este în cea mai bună formă şi cel mai apropiat de ei.
Traffic Manager este capabil să treacă în mod automat la alt endpoint atunci când cel original este oprit.
Noi putem foarte uşor să adăugăm endpoint-uri cu configuraţie diferită sau versiune diferită a aplicaţiei noastre şi să verificăm comportamentul lor (testând suprafaţa cu noi caracteristici).
Traffic Manager ne permite să trecem automat la un endpoint funcţional dacă originalul este oprit.
Fiind capabil să înregistreze endpoint-uri multiple de la centre de date diferite, traficul va fi distribuit celui mai apropiat endpoint pe baza timpului de răspuns şi a altor configuraţii – în funcţie de metoda de echilibrare a volumului de date pe care am selectat-o.
Nu puteţi include în Traffic Manager servicii precum Service Bus, SQL Azure sau Storage. În general, nu doriţi să faceţi aşa ceva.
Nu vă este permis să monitorizaţi _endpoint-_uri externe, de la locaţia voastră sau din alte subscripţii Azure.
Nu aveţi acces la monitorizarea configuraţiei. Clienţii nu pot seta cât de des să fie verificată starea _endpoint-_urilor.
În continuare, veţi vedea trei cazuri de utilizare a serveruluiTraffic Manager.
Dacă aveţi un web site care este pus în funcţiune în mai multe centre de date, echilibrarea volumului de trafic poate fi făcut cu uşurinţă prin utilizarea Traffic Manager-ului. Dacă volumul unui web site creşte sau a scăzut, traficul va fi redirecţionat automat către alt endpoint.
Atunci când aveţi un sistem care este distribuit în centre de date diferite şi aveţi o normă de a specifica dacă un endpoint poate accepta clienţi noi sau nu, puteţi folosi cu succes Traffic Manager. Ar trebui să implementaţi calea url care este utilizată pentru a verifica starea endpoint-ului cu scopul de a returna un cod de eroare HTTP diferit de 200 OK, dacă endpoint-ul curent nu mai poate accepta clienţi noi.
Puteţi utiliza traffic manager numai drept mecanism de reluare în caz de eşec pentru web site-urile voastre şi să configuraţi ultimul failover endpoint din Traffic Manager pentru a returna numai o simplă pagină HTTP. În acest fel, chiar dacă sistemul vostru este oprit, clienţii vor putea să vadă ceva „frumos”.
Pro
• Uşor de utilizat,
• Metode diferite de echilibrare a volumului de date introduse,
• DNS TTL.
Contra
• Nu se pot specifica endpoint-uri externe;
• Nu se pot specifica endpoint-uri din subscripţii diferite;
• Un punct de eşec dacă Traficul este oprit;
Costuri
Când calculaţi costul utilizării Traffic Manager-ului în sistemul vostru, ar trebui să luaţi în considerare și
numărul cererilor DNS pentru managerul de trafic.
Express Routes este o conexiune privată între reţeaua voastră (din locaţie) şi Azure Data Centers. Atunci când utilizaţi această funcţie, aveţi o conexiune directă cu Azure Data Centers, care nu este împărţită cu alţi utilizatori. Din această cauză, o conexiune ca aceasta nu este numai rapidă, ci şi extrem de sigură. Întregul trafic de la clienţii care utilizează această funcţie este împărţit în două „canale”. Un canal este folosit pentru traficul care ajunge la serviciile publice Azure, iar al doilea pentru traficul care ajunge la resursele Azure Compute. Pentru fiecare dintre aceste canale (Direct Layer 3 şi Layer 3), există viteze diferite care sunt garantate.
Conexiunile care sunt făcute prin Express Route trec printr-o conexiune privată care nu este conectată la „internetul cunoscut”.
Datele transmise prin cablu sunt în siguranţă deoarece conexiunea este printr-un canal privat care nu poate fi accesat de către utilizatori publici.
Vitezele oferite prin această conexiune sunt mai mari, iar lăţimea de bandă vă este dedicată.
Conexiunea directă între voi şi centrul de date Azure reduce latenţa care există în mod normal între două endpoint-uri.
Există opţiuni diferite de lărgime de bandă care sunt disponibile de la 10 Mbps şi până la 10 Gbps.
Da, avem chiar şi exces de conexiune. Conectivitatea Layer 3 (prin Network Service Providers) poate avea un exces de conexiune (conexiune Activă).
Dacă deja utilizaţi Site to Site sau Point to Site şi doriţi să migraţi la Express Route, veţi descoperi că migrarea se poate face foarte uşor.
Toate reţelele virtuale care sunt conectate la aceeaşi Express Route pot comunica unele cu altele. Veţi putea conecta reţele virtuale din diferite subscripţii, atâta timp cât toate sunt conectate la aceeaşi rută expres.
Toate Reţelele Virtuale conectate la aceeaşi Rută Express fac parte din acelaşi domeniu de trafic şi nu sunt izolate între ele. Dacă doriţi izolare între acestea, atunci va trebui să creaţi rute expres diferite pentru fiecare dintre ele.
În acest moment există o limită de până la 4.000 de rute pentru peering public şi 3.000 de rute pentru peering privat. S2S sau P2S nu pot fi folosite în combinaţie cu Express Route.
Nu puteţi utiliza ambele metode pentru a vă conecta la infrastructura Azure. Dacă folosiţi Express Route, nu veţi putea să utilizaţi S2S sau P2S pentru aceeaşi conexiune.
Fiecare Rută Expresă poate fi asociată numai cu un singur furnizor. Din această cauză, nu puteţi asocia aceeaşi Express Route cu mai mulţi furnizori.
Extensiile de conectivitate Layer 2 la Azure nu sunt suportate.
Mai jos puteţi găsi patru cazuri de aplicare în care Express Route poate fi utilizat cu succes:
Atunci când folosiţi Azure Media Services pentru derularea video, veţi dori să puteţi să derulaţi conţinut live prin Azure Media Services tot timpul. În acest caz, aveţi nevoie de o conexiune stabilă între studiourile voastre şi Azure Data Centers. Express Route poate fi o opţiune bună pentru voi.
Dacă infrastructura şi serviciile voastre sunt pe Azure, atunci veţi avea nevoie în faza de monitorizare şi suport de o Conexiune Express între voi şi Azure. Echipa de suport trebuie să poată accesa serviciile voastre Azure într-un mod rapid şi de încredere.
Când utilizaţi Azure Storage sau SQL Azure pentru a memora datele voastre, veţi dori de asemenea o latenţă scăzută şi o conexiune rapidă între datele voastre şi infrastructura din locaţia voastră. Express Route poate fi o soluţie pentru această problemă.
Dacă sunteţi o bancă şi aveţi nevoie de o conexiune sigură între site-urile din locaţie şi serviciile voastre Azure, Express Route poate fi o soluţie foarte bună. Prin utilizarea sa, veţi avea o conexiune sigură care nu poate fi accesată de pe internet.
Pro
• Rapid
• Sigur
• De încredere
• Exces
• Uşor de conectat
Contra
• Nu este disponibil în întreaga lume încă.
Costul se bazează pe traficul expediat departe. O parte din acesta este gratuit, inclus în subscripţie. Depăşirea lui va fi taxată cu un tarif mic per GB. Traficul de transfer date inclus poate să difere în funcţie de viteza portului furnizorului Exchange pe care preferaţi să o utilizaţi.
Atunci când calculaţi costurile utilizării Express Route, ar trebui să luaţi în considerare: viteza port furnizor schimb și transferul de date expdiate.
O reţea virtuală este o reţea „privată” pe care o puteţi defini în cadrul infrastructurii Azure. În fiecare reţea virtuală (Virtual Network), utilizatorii au posibilitatea de a adăuga servicii Azure şi VM pe care şi le doresc şi de care au nevoie.
Numai VM-urile şi serviciile Azure din aceeaşi reţea virtuală se pot vedea unele pe altele. Implicit, resursele externe nu pot accesa resurse din Virtual Network. Bineînţeles, utilizatorii pot configura o reţea virtuală care să fie accesată din lumea exterioară.
Ne putem imagina o Reţea Virtuală drept o reţea privată pe care o creăm acasă sau la serviciu. Noi putem adăuga la aceasta orice resurse, putem aloca IPuri specifice şi Subnet Masks, putem deschide diverse porturi pentru acces extern şi aşa mai departe. Este o reţea în interiorul unei reţele, dacă putem să spunem aşa. De multe ori mă refer la ea ca şi Reţea Privată, deoarece îi puteţi adăuga resurse şi puteţi limita accesul resurselor externe la ea.
Utilizând Virtual Networks, vă puteţi crea propriul vostru colţ privat în Azure, unde numai voi aveţi acces. Toate resursele voastre sunt izolate de restul lui Azure.
În general, există trei tipuri de configuraţii utilizate cu Virtual Networks:
Cloud-Only – O reţea virtuală cu resurse numai în Azure, utilizată pentru a gestiona, securiza şi a izola resursele cloud.
Cross-Premises Virtual Network – Pentru soluţii hibride, unde Virtual Network este utilizat pentru a crea un spaţiu în Azure care poate fi accesat şi este integrat cu o reţea din locaţie. Ambele reţele formează o singură reţea care permite accesul reciproc.
No-Virtual Network – No-Virtual Network utilizat pentru resursele cloud.
În cazurile în care aveţi nevoie să conectaţi soluţia voastră din locaţie cu resursele Azure, Virtual Network este o necesitate şi trebuie să vă gândiţi la ea încă din primul moment.
Odată ce integraţi reţeaua voastră cu o Reţea Virtuală, vă puteţi accesa resursele direct prin numele lor DNS (de exemplu, numele Virtual Machine).
Atunci când creaţi o reţea virtuală, Azure vă poate genera programul care trebuie rulat pe IT pe reţeaua voastră din locaţie. Utilizând aceste script-uri, cele două reţele pot deveni una singură, fără configurare adiţională.
Când creaţi o reţea virtuală aveţi posibilitatea de a stabili un interval de IP şi o mască subnet. Vă puteţi crea propria configuraţie pe baza nevoilor voastre şi a cerinţelor reţelei.
În Virtual Network resursele vor avea un IP static care nu se modifică în timp. De exemplu, o maşină virtuală (VM) va avea acelaşi IP şi nu se va schimba. În plus, puteţi atribui manual un IP specific resurselor voastre din intervalul IP al reţelei voastre virtuale.
În acest moment, numai Virtual Machnes şi resurse PaaS pot fi adăugate unei Virtual Network. Resurse precum Service Bus nu pot fi încă adăugate unei reţele virtuale.
Pentru instalare şi configurare avem două instrumente pe care le putem utiliza:
• Netcfg –un fişier geneat de platforma Azure, care poate fi utilizat pentru a face diferite configurări.
• Portalul de management.
Puteţi defini numărul de subnet-uri, atâta timp cât nu se suprapun. Aceleaşi reguli se aplică pentru orice reţea (din locaţii sau cloud).
Virtual Network ne permite să folosim orice tip de IP, de la adrese IP publice la orice tip de intervale IP.
Virtual Network este o reţea Layer 3 care este responsabilă cu expedierea şi dirijarea mesajelor.
Există trei tipuri de protocoale susţinute în acest moment: TCP, UDP, ICMP.
Conexiunile VPN sunt suportate (RRAS – servere Remote Access şi Windows Server 2012 Routing).
Toată distribuţia Linux care este suportată pe Azure poate fi utilizată într-o reţea virtuală.
Odată ce o resursă, cum ar fi un aparat virtual (VM), a fost creată şi pusă în funcţiune, nu mai poate fi mutată pe o reţea virtuală. Acest lucru se întâmplă deoarece informaţia reţelei este obţinută în timpul punerii în folosinţă. Bineînţeles, puteţi repune în folosinţă aparatul vostru, dar va interveni o mică perioadă de nefuncţionare.
Puteţi utiliza VPN numai pentru Windows OS (W7, W8, Windows Server 2008 R2 64b, Windows server 2012).
În acest moment, numai resursele Virtual Machines şi PaaS pot fi adăugate unei reţele virtuale. Alte tipuri de servicii nu pot fi adăugate la Virtual Network.
O regiune virtuală poate fi definită numai într-o singură regiune. Dacă doriţi să creaţi o reţea inter-regională, va trebui să creaţi mai multe reţele virtuale şi să le conectaţi între ele.
Cea mai mică reţea subnet suportată este /29 iar cea mai mare este /8.
Deoarece Virtual Network este o reţea Layer 3, nu există suport pentru VLAN-uri (care operează la Layer 2).
Tracert
Acest instrument de diagnostic nu poate fi folosit într-o reţea virtuală.
IPv6
În acest moment nu există suport pentru IPv6.
Difuzare (Broadcast)
În acest moment nu există suport pentru difuzarea pachetelor.
Multicast
În acest moment nu există suport pentru multicast.
Pachete încapsulate IP-in-IP
În acest moment nu există suport.
Generic Routing Encapsulation (GRE)
În acest moment nu există suport.
SQL DB
În acest moment SQL DBs nu pot fi utilizate în combinaţie cu Virtual Networks.
Vă prezint mai jos patru cazuri în care aş utiliza Virtual Network:
În acest caz, veţi dori ca toate resursele voastre să facă parte din aceeaşi reţea şi să fie izolate de lumea externă.
Atunci când aveţi nevoie de mai multe resurse cu putere de calcul (VM) şi doriţi să creşteţi resursele din locaţia voastră într-un mod simplu şi sigur, Virtual Network vă poate crea mediul sigur pentru a face aşa ceva.
Când soluţia voastră este găzduită la locaţie dar şi în cloud, Virtual Network poate fi folosit cu succes pentru a unifica sistemul şi resursele.
Dacă doriţi să accesaţi VM într-un mod sigur şi de încredere din reţelele voastre proprii, atunci Virtual Network este o necesitate.
Pro
• Uşor de configurat,
• Resurse izolate de Internet,
• Sigur .
Contra
• Pot fi utilizate numai resurse VM şi PaaS,
• IPv6 nu este susţinut încă.
Când calculaţi costul pentru Virtual Network, ar trebui să luaţi în considerare următoarele componente: transfer de date expediate (Inter V-NET) și durata VPN Gateway.
În acest articol, am descoperit diferite modalităţi de management al reţelelor pentru aplicaţiile care sunt găzduite de Microsoft Azure. În funcţie de nevoile voastre, ar trebui să luaţi în considerare aceste servicii.
de Ovidiu Mățan
