blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

CDP-B337 - Lessons from Scale with Mark Russinovich

Thursday, October 30, 2014 6:01 PM Christoph Wilfing
Der Meister selbst persönlich. Ich freu mich. Es geht um Erfahrungen mit Azure und Applikationen die in Azure gelaufen sind. Es werden aber keine Namen genannt sondern nur Architekturen. (bis auf eine Ausnahme) Case - Election Results Grosser US Staat wollte die Elections auf den Automaten einfach online auswerten und dort entsprechend abfackeln at Scale. Im September eine kleine Election hat funktioniert, aber es war eng was Performance Themen betraf. Im November wollte man wesentlich grössere Elections machen. Review der Architektur stand an. Im Wesentlichen wie im Bild zu sehen - eine Web Rolle, eine Worker Role sowie Database. Die Daten kommen von den Wahlmaschinen direkt in die Azure Blobs, werden vom Worker aufgearbeitet in die Datenbank und dort dann über Web Role wieder abgefragt. Das ganze Fault Tolerant mit zweiter Kopie im zweiten RZ und Azure Traffic Manager als DR Architecture. HochRechnung: 1 Web Request, 10 SQL Queries, based 10.000.000 Million Page Views, 695 Page Views/s wurden geschätzt auf der Basis der September Daten. Problem: Azure DB, 5000 Connections, 180 Concurrent Requests, 1000 Requests per Second. Wenn man die Hochrechnung durchkalkuliert - das geht sich ned aus im Azure. Solution: Cache zwischen FrontEnd und BackEnd DB mit 40.000 Requests/s pro Instance. Learning: Cache between Database and Web Role hilft! Case - PAAS Customer im Building Sektor, machen Building Plants und dgl. mit einer bestehenden OnPrem Applikation. Das aktuelle OnPrem Design wurde folgendermassen in Azure umgesetzt. ASP.NET moved to Web Role, application logic in Worker Role, SQL als IaaS => Warum ==> Stored Procedures wurden verwendet die in Azure DB nicht funktionieren Ergebnisse vom ersten Test: OnPrem App hat ca. 33.174 Requests bei 200 usern, Azure rund 10.135 OnPrem hatte Web und SQL auf einer Maschine. Im Azure getrennt, der Hop dazwischen war das Problem. Der Vorteil dieser Rollen getrennt voneinander zu scalen war nicht so wichtig, daher wurde Worker und SQL Role zusammengelegt um die Latency und den Netzwerkhop zwischen den Rollen zu sparen. Azure DB Througput aufgrund falscher VHD Layouts - 1844 IOPS / 15.2 MB/s Optimized Configuration, 16 Disks, data + tempdb auf einer VHD mit 5378 IOPs / 336,15 MB/sec Nach der Optimierung => Azure Throughput war slightly higher than onPrem. (ich konnte es aber auf den Folien nicht 100% erkennen, es war aber durchaus um den Faktor 1.2 höher) Case - Move Streaming (BlinkBox) "Catch me if you can" - PaaS Streaming Service Web Role + Database + Azure Blog Storage. Dort liegen die Filme und in der Datenbank nur die Metadaten. Cache zwischen Web Role und Database um die Requests zu cachen. Problem: Wenn der Cache nicht in 2 Sekunden geantwortet hat, dann ist die Web Role zur Database gegangen. Die Datenbank ist aber unter Stress in die Knie gegangen. (Beispiel die Cache Role rebootet) Lösung: Cache auf den Web Servern direkt, dann fallts ned auf weil die Web Role ja auch weg ist und der Cache nicht einzeln ausfallen kann Case - Cars Connected Car Company mit Daten der Autos die ihre Infos in Azure reinwerfen um dort Auswertungen zu machen. (Car fails,...) Azure Service Bus mit Messages die an eine Worker Rolle gegeben werden un ddie Workerrolle schaufelt das in die Datenbank. geplant waren rund 10.000 Requests, das Ergebnis waren - "Far less than 10.000 Requests as expected." Problem: Synchronous Message processing => die Azure Service Bus messages dürfen nicht synchron abgerufen werden sondenr einfach parallel - einen Request - 20ms auf alle Messages warten die daherkommen in der Zeit und diese dann parallel abarbeiten Processing Messages war auch Sequentiell=> auch hier parallel einfach weil alle Messages komplett unabhängig voneinander sind. ... Viele weitere Beispiele   für mich sind folgende Punkte immer wieder aufgekommen: Asynchron vor Synchron Wenn möglich immer versuchen die Kommunikation zwischen Komponenten oder Work asynchron zu machen. Wenn etwas warten muss, dann kostet das Zeit. Scale Out not Scale Up Parallel arbeiten hilft wesentlich mehr als die einzelne Kiste dicker machen. Die kochen halt auch nur mit Wasser und irgendwann ist jede CPU am Ende, jedes Storage am Limit. Wer also die Daten in Chunks aufteilt und parallel arbeitet kann kumulativ einfach mehr erreichen. Cache where needed Wenn Sinnvoll immer die Daten cachen. Ähnlich wie bei Synchron / Asynchron - wer auf ein Ergebniss wartet hat a schlechtere User Expirience. Warten ist immer schlecht.   Azure Lessons VIP Swap Very small number of Customers Worte von Herrn Russinovich waren ungefähr "Couple of hundred customers could not manage Environment", für uns klingt das eher dramatisch, aber in Azure Scales ist das halt im Rahmen der normalen Fehlerrate. Dafür gabs sogar an "The Register" Artikel Microsoft Azure goes TITSUP (Total Inability To Support Usual Performance) Whats a VIP Swap Production hat IP / DNS die verwendet wird, Stage Umgebung hat Temp IP / DNS. beim VIP Swap wird Stage auf Production gewechselt. Man kann also die gesamte Architektur ändern durch einen VIP Swap.   VIP Swap Internals:  RDFE wird für Monitoring verwendet und durch eine Race condition beim Update von Stage auf Production kommt es zu doppelten Daten respektive Überschreibungen und RDFE lässt aufgrund der Inconsistency keine Management Operations mehr zu. RDFE Developer Explanation: "Unintuitive behaviour of ADO.NET" Ja das stand so auf den Folien! Subscription Delete Operator regular clean up internal Azure Subscriptions - das wird halt gemacht für Subscriptions die intern angelegt werden oder als Microsoft INTERNAL markiert werden. Diese Deletes dürften eine ganze Menge gewesen sein und diese haben sich quasi etwas aufgestaut. Damit es schneller geht hat der Operator ein "Batch Delete" durch gewunken (vorbei am Prozess der das auch gestoppt hätte) Leider waren auch eine Menge an Subscriptions dabei die von Microsoft für Customer angelegt wurden und deshalb als "internal" markiert waren. Learning: Use Soft-Delete, Resource inaccessable to customer, wait 90 days, really delete. Storage Certificate Expiration 22 Februar 2013 | 12:29 PM no SSL Connection to Storage Azure Problem that shuld never happen ever (=> es fällt auf das TheRegister hier immer als erster schimpft) Was wirklich passiert ist Automatisierter Process überprüft die Expiration von Zertifikaten im Secure Store (Ich vermute mal er meinte HSM Module), Wenn diese in 180 Tagen ablaufen, dann muss ein neues Zertifikate her. Breakdown hat begonnen mit dem 7 Januar. Das Storage Team hat seine Zertifikate aktualisiert und das Zertifikate im Secure Store aktualisiert. Was vergessen wurde - die Deadline für das Rollout des neuen Zertifikats auf die Storage VMs. Bedeutet es ist alles weitergelaufen, weil der Check am BackEnd im TPM ja "ok" war. Aber wichtigere Deployments haben das Cert Deployment in Produktion immer weiter nach hinten geschoben bis ... Learning: Monitoring überprüft nicht nur die HSM DAten sondern auch die Production Endpoints Sprich - überprüf immer den gesamten Life Cycle. not just a part of it.   Letzte Folie Cache aggressivle to hide latency Async with queues when possible Process in batches to minimize round trips Partition data and compute to scale out Roll out with monitored slices Log excessively War a gute Session, klingt alles spannend. Man kriegt halt so ein wenig das Gefühl doch sehr klein zu sein und Azure zu betreiben dürfte die ein oder andere Schlaflose Nacht bedeuten. LG Christoph
Azure | Cloud | Microsoft | Office365
mehr

TechEd Automation in System Center Azure Pack #CDP-B245

Tuesday, October 28, 2014 4:25 PM Christoph Wilfing
Nächste Session auf dem Plan, CDP-B245, volle Bezeichnung: "Automation in System Center, Azure Pack, and Microsoft Azure with roadmap for the next release" Die Story ist natürlich über System Center Orchestrator bzw. System Management Automation im Windows Azure Pack. Ziel ist wie immer - manuelle Prozesse durch Automatisierung zu optimieren und more predictable zu machen. Das Ergebniss soll immer gleich sein und eine Standardisierung erlauben. System Center Orchestrator SCO kennt man recht gut - ein Graphischer Run Book Designer der erlaubt den Prozess selbst zu zeichen und entsprechend auf einem Runbook Server laufen zu lassen. Integration Packs die andere fremde Systeme integrieren und es erlauben unterschiedlichste Systeme zu steuern. (SQL  Datenbank um alles drin zu speichern und perfekte Lösung) Ziel des SCO - Datacenter Orchestration. Auf der Demo wurde jetzt a bissl SCO mit Runbook Designer hergezeigt, nichts Besonderes. Also Anlegen einer VM aus einem Request heraus. Service Management Authomation Ziel ist hier aber primär Cloud und Azure Pack. Die "normale" DataCenter Automation ist hier nicht Zielgruppe. Es kommt zwar unterm Strich auch eine VM raus, aber der erste Blick zeigt, es geht um IT Admin (Fabric Admin) und Customer - also Multi Tenant dürfte hier sehr im Vordergrund stehen. Das Windows Azure Pack ist ja quasi ein Abklatsch von Azure mit Webseite, für IT Pro und Customer. Man kann auch ähnliche Services anbieten. Customer kann hier genauso eine VM anfordern mit den dahinterliegenden Rules die der IT Pro vorher festlegt. (also Serviceklassen, VM Templates,...) Dahinter gibts aber natürlich auch einen SCVMM der dann zum Beispiel das Provisioning der VMs macht. Wesentlicher Unterschied der mir hier auffällt. Es gibt keinen Runbook Designer - alles läuft als Powershell. Es gibt nix grafisches das dir den Prozess zusammenbaut, sondern alles per Powershell basteln. Das klingt jetzt etwas ungut, aber es hat einfach nur eine etwas längere Lernkurve aber ist dafür um einiges flexibler. Cooles Feature - man kann die ganzen Credentials an einem Ort im Azure pack secured speichern und von den Scripts dann zur Laufzeit abholen. Nichts mehr mit speichern der Creds im Script. Sehr spannende Sache. Alles in allem - das SMA schaut nach viel Powershell aus das man halt auch beherrschen muss. Ist aber the way to go wenn man PrivateCloud im Azure Pack betreiben will. SCO - wenn ich eher traditionelle System Center Umgebung hab. Kann zwar aus eigener Erfahrung sagen das SCO sicher nicht ohne  Powershell auskommt, aber zumindest gibts an graphischen Prozessflow. (mit Visio gehts auch im Azure Pack) Features to come for SMA: Graphischer Editor für das Handling der Prozesse, ja klar - was im SCO scho als eigene App drin ist, kommt auch als Editor im Web fürs SMA Role Based Access Control Grant Access to Automation Resources Powershell Module natürlich auch the other way around, einfach per Powershell die Azure Resourcen angreifen können.   Als neue Resource around kann man sich die Technet Gallery anschaun. es kommen dort neue Runbooks die man verwenden kann und auch viel Support in dem Bereich. Features to come for SCO Runbooks: Es kommt ein Migration Tool mit dem man Runbooks exportieren / importieren kann. Powershell: Powershell Module für eingebaute Integration Packs und so Sachen. LG Christoph
Event | Cloud | Azure
mehr

Hyper-V vNext-Features #TEE14

Tuesday, October 28, 2014 3:29 PM Christoph Wilfing
Auf der TechEd tut sich wirklich viel. Neben vielen Informationen rundum werde ich versuchen ein paar Highlights aus meinen Sessions zu bloggen. Schaut wahrscheinlich etwas wild aus aber ich versuch es sauber zu halten. Wenn es Fragen dazu gibt, einfach melden und ich versuch diese zu beantworten. In der Session CDP-B225 Software Defined Compute in the Next Release of Windows Server Hyper-V (nachzulesen unter http://teeu2014.eventpoint.com/topic/list ) gab es ein von @VirtualPCGuy ein paar wirklich she interessante Rolling Upgrade: Cool. Endlich können wir Cluster mit 2012R2 bauen. in den selben Cluster einen "neuen" Windows Server joinen und VMs einfach Live Migrieren und damit Step by Step einen Cluster updaten Backup Change Tracking: Endlich auch eine brauchbare Version um mit VSS und Changed Block Tracking Backup wesentlich besser zu skalieren. Cluster Improvements Cluster Nodes werden beim Sterben des Services auf Isolated gesetzt (man kann ja nicht wissen ob die VM wirklich weg ist wenn der Clusternode nicht mehr kommuniziert) VMs werden im ersten Schritt nicht sofort neu gestartet, nach 4 Minuten springt der Cluster aber an und restarted die VMs auf anderen Hosts (Nur für Hyper-V Workload, nicht für normale Resourcen). Isolated und kommt der Host öfter zurück wird er Quarantined und alle VMs just in Case weg live migriert, guter Plan (wir trauen keinen Hosts die etwas wankelmütig sind.) Hardware Accelerated Live Migration: Live Migration mit SMB Direct über RDMA sind noch immer die einzigen (auch VMware kann das nicht!) mit dem man den Live Migration Prozess beschleunigt. (im Lab bis zu 16GByte/s erreicht und schön langsam werden die Adapter auch bezahlbar) More Improvements to come. LG Christoph
Cloud | Hyper-V | Event
mehr