Articolul prezintă Azure CDN din trei puncte de vedere:
Scopul principal al articolului este să evidențieze ce se poate şi ce nu se poate face cu Azure CDN.
Dorim să prezentăm funcţionalitatea şi feature-urile disponibile în momentul de faţă (Q3, 2016) în Azure CDN. Pe pagina web Azure, veţi găsi multe informaţii utile şi sunt sigur că deja aţi consultat-o.
Comparativ cu ultimii ani, Microsoft face acum un mare pas, semnând contracte cu Akamai şi Verizon (furnizori majori de servicii CDN).
Aceasta a fost o alegere foarte bună, deoarece e nevoie de mulţi bani şi de mult efort pentru a-ţi dezvolta propriul CDN. Sunt anumite lucruri pe care nu e nevoie să le dezvolţi sau să le creezi de unul singur dacă nu ai nevoie de feature-uri customizate.
Nu aveţi nevoie de un contract cu fiecare furnizor. Aveţi nevoie doar de un abonament Azure (Azure Subscription), fără a fi nevoie de un contract sau de o factură de la Akamai sau Verizon.
În general, feature-urile CDN oferite de aceştia sunt similare. Există mici excepţii, cares-ar putea să (nu) aibă impact asupra afacerii dumneavoastră. Pe baza listei de feature-uri disponibile, putem spune că Akamai este varianta basic, în timp ce Verizon are nişte trăsături adiţionale. Ambele oferă funcţionalitatea de bază cerută de CDN.
Elementele Verizon care sunt disponibile doar pe Azure CDN sunt:
În continuare, vom prezenta feature-urile pe care Azure CDN de la Akamai şi Azure CDN de la Verizon le au în comun:
Azure CDN de la Verizon este disponibil în două versiuni, Standard şi Premium. Bineînţeles, exceptând preţul, există feature-uri disponibile doar pentru versiunea Premium, precum:
După cum se observă, sunt multe feature-uri disponibile pentru Azure CDN. Pentru situaţii obişnuite, puteţi folosi produsul fără probleme.
Vom analiza funcţionalităţile sau feature-urile pe care nu le avem în Azure CDN, deşi, de multe ori, presupunem că acestea sunt disponibile.
Funcţionalitatea considerată disponibilă n Azure CDN este Shared Access Signature pentru Blob Storage. Shared Access Signature (SAS) este unul dintre cele mai des utilizate și dintre cele mai puternice feature-uri pentru Blob Storage. În cadrul Azure CDN avem posibilitatea de a pune în cache un blob utilizând URL-ul complet, incluzând URL-ul.
Datorită acestui fapt, oamenii au impresia că Azure CDN ţine cont de validitatea SAS și, odată ce SAS expiră, cache-ul va fi invalidat.
De fapt, în momentul actual Azure CDN tratează URL-ul unui Blob Azure care are SAS ca pe oricare alt URL. Dacă conţinutul poate fi accesat, acesta va copia payload-ul și îl va replica pe CDN. Conţinutul va fi îndepărtat din nodurile CDN doar când valoarea TTL din CDN, care nu are legătură cu SAS, expiră.
Chiar dacă Azure CDN oferă suport pentru DNS customizat, precum și penru HTTPS, nu înseamnă că puteţi utiliza HTTPS folosind numele dumneavoastră de domeniu. Poate părea bizar faptul că două trăsături sunt suportate, însă nu este suportată combinaţia dintre cele două.
Astfel, dacă aveţi nevoie de HTTPS, trebuie să folosiţi Azure CDN DNS. Acest feature este extrem de votat și dorit pentru CDN, pe Azure Voice, de aceea, va avea suport în curând.
Când utilizaţi Azure CDN, trebuie să vă amintiţi că, deși se oferă suport pentru HTTPS, în acest moment, suportul lipsește pentru certificatele de tip client. Puteţi utiliza doar certifcate SSL furnizate de CDN.
Din acest motiv, nu avem suport pentru certificatele de tip client pe domenii DNS customizate pentru Azure CDN, dar lucrurile se vor îmbunătăţi în curând.
Noul protocol de Internet - dacă îl putem numi așa - nu are încă suport. în general, acest lucru nu este o piedică, cu excepţia situaţiei în care aveţi o aplicaţie web complexă și doriţi să diminuați numărul interogărilor făcute de browser-ul client. În aceste situaţii, utilizarea Azure CDN s-ar putea să nu fie foarte simplă, dar există soluţii temporare la acestea.
Unii furnizori CDN ne dau posibilitatea să specificăm un URI care se poate folosi pe post de fallback când conţinutul nu este găsit în locul originar. Acest lucru este util când lucraţi cu o aplicaţie în care disponibilitatea de timp este critică și trebuie să furnizaţi o locaţie validă pentru tot conţinutul.
Evident, cu puţină imaginaţie, puteţi rezolva această problemă destul de ușor. Dacă poziţionaţi Azure Traffic între Azure CDN și conţinutul dumneavoastră, veţi putea specifica o listă de URI-uri, de rezervă.
Multe persoane solicită acces la datele brute ale log-urilor, similar lui Azure Storage. Acesta ar putea fi un feature util, dar am câteva îngrijorări.
Principalul scop CDN este să realizeze un cache și să servească conţinutul deseori solicitat dintr-o locaţie cât se poate de apropiată de client. Se folosește în cazurile în care RPS (requests per second/interogăripe secundă) este ridicat. Generarea unui fișier cu date brute ar putea să fie scump și s-ar putea ca rezultatul să fie niște log-uri care sunt mari. Procesarea acestor fișiere s-ar putea să fie scumpă.
Este important să ne amintim că unele dintre aceste feature-uri sunt deja planificate de echipa Azure, iar, în viitorul apropiat, s-ar putea să le găsim în Azure CDN. De asemenea, nu uitaţi că o soluţie la cheie (out-of-the-box) este greu de găsit, deși este posibilă cu puţină imaginaţie.
Vom analiza feature-urile Azure CDN care lipsesc în acest moment. Le-am discutat în ultima postare, iar aici le vom explica.
Dacă aveţi nevoie de un sistem CDN care oferă suport pentru SAS, pe lângă Azure Store, trebuie să daţi dovadă de inventivitate. Cea mai simplă soluţie este replicarea conţinutului în conturi Azure Storage multiple (Azure Storage Accounts) sau în același cont Storage (Storage Account) (dacă problema ţine de viteza de descărcare/download) și să creaţi un web endpoint (ce poate fi găzduit de un web app) care va furniza locaţiile de unde conţinutul poate fi descărcat.
Acest web endpoint poate avea un mecanism Round Robin pentru a deservi diverse locaţii.
Utilizând această abordare, veţi avea nevoie și de un mecanism care replică conţinutul în locaţii multiple. AzCopy s-ar putea să fie o soluţie la cheie (out-of-the-box).
Azure CDN și Azure Storage utilizează același sistem de stocare. În acest moment, nu avem suport pentru HTTPS și pentru domenii customizate DNS (Custom DNS Domains). În acest caz, dacă realmente aveţi nevoie de HTTPS, singura soluţie este ca deservirea conţinutului să fie făcută de pe Azure Web App. Nu avem multe opţiuni momentan.
Scenariul este similar cu cel anterior. Nu avem multe opţiuni. Cel mai bine este să folosiţi o Azure Web App și să deserviţi conţinutul binary de acolo.
Nici o soluție, la fel ca și la Azure Web App.
Pentru aceste situaţii, avem o soluţie simplă. Putem aplica abordare prezentată în exemplul SAS Suport. Trebuie să avem aplicaţii web Azure multiple (Azure Web Apps) care pot deservi locaţia conţinutului și care pot adăuga Azure Traffic Manager în faţa lor.
Dacă aveţi nevoie de aceste log-uri, trebuie să folosiţi Azure Blob Storage. Ar trebui să folosiţi abordarea de mai sus şi să activaţi log-urile pentru fiecare cont de stocare Azure (Azure Storage Account).
După cum putem vedea, există multe feature-uri disponibile în Azure CDN. Evident, nu vom putea găsi o soluţie perfecă care să ne asigure toate lucrurile de care avem nevoie. Acest lucru e valabil şi pentru Azure CDN. Trebuie, însă, să reţinem că o bună parte din feature-urile care lipsesc deocamdată au statusul In Progress pe portalul de feedback al Azure. Acest lucru presupune că vom avea suport şi pentru acestea.