Mit einem Replikat ist eine Blazor-Server-Insel ein gewöhnlicher Webserver: Die Verbindung geht zum einzigen Prozess, der Zustand liegt in dessen Speicher, und ein Neustart beendet alles. Mit zwei Replikaten stimmt davon nichts mehr, wenn nichts dafür getan wird. Diese Lektion beschreibt, was die Kladde dafür braucht, und stellt jede Einstellung auf ihren Grund. Sie nennt ebenso klar, was nicht ausgeführt wurde: Nichts in dieser Lektion lief gegen Azure. Was übersetzt wurde und was lokal lief, steht im Kasten „Stand der Prüfung“.
Wo die Kladde steht
Die Lektion setzt aus K2 die Lektionen 2.9.4 („Azure vor dem ersten Deploy“) und 2.9.5 („Ausliefern mit azd“) voraus). K2 Lektion 2.13.3 („SignalR skalieren“) hat im Abschnitt „Blazor Server und Container Apps“ vorbereitet, dass die Inseln ab zwei Replikaten Sitzungsaffinität und gemeinsame Schlüssel brauchen. Managed Identity, Key Vault, Blob Storage, Gesundheitsprüfungen und Lasttests behandelt K3 (Lektionen 3.3.1, 3.3.2, 3.6.3, 3.4.5 und 3.8.6); sie werden hier vorausgesetzt. Neu ist die Bereitstellung der Kladde mit zwei Replikaten: eine Bicep-Beschreibung für die Web-App, die Schlüssel in Program.cs und der Abschnitt „Betrieb“ der Entscheidungsmappe. Die Lektion „Render-Modi wählen und begründen“ hat festgelegt, welche Seiten Server-Inseln sind, „Zustand: Vorrendern, Persistenz, Wiederverbinden“, was ein Abbruch kostet, und „Leistung und Größe“ liefert die Rechnung zum Speicher je Schaltkreis.