Premium-Tarif für Azure Functions
Der Elastic Premium-Tarif für Azure Functions ist eine dynamische Staffelung für Hostingoption für Funktions-Apps. Andere Hostingplanoptionen finden Sie im Artikel zu Hostingplänen.
Wichtig
Azure Functions kann auf der Azure App Service-Plattform ausgeführt werden. Auf der App Service-Plattform werden Tarife, die Premium-Apps für Tariffunktionen hosten, als Elastic Premium-Tarife mit SKU-Namen wie EP1 bezeichnet. Wenn Sie Ihre Funktions-App in einem Premium-Tarif ausführen möchten, stellen Sie sicher, dass Sie einen Tarif mit einem SKU-Namen erstellen, der mit einem „E“ beginnt, z. B. EP1. App Service Plan-SKU-Namen, die mit einem „P“ beginnen, z. B. P1V2 (kleiner Premium V2-Tarif), sind tatsächlich P1V2 Da es sich um dedizierte Tarife und nicht um Elastic Premium Tarife handelt, werden Tarife mit SKU-Namen, die mit einem „P“ beginnen, nicht dynamisch skaliert und möglicherweise ihre Kosten erhöhen.
Das Hosten von Funktionen im Premium-Plan bietet die folgenden Vorteile:
- Verwalten von Kaltstarts durch ständig betriebsbereite Instanzen
- VNET-Konnektivität
- Unterstützt längere Laufzeiten.
- Auswahl an Premium-Instanzgrößen
- Besser vorhersagbare Preise im Vergleich zum Verbrauchsplan
- App-Zuteilung mit hoher Dichte für Pläne mit mehrere Funktions-Apps
- Unterstützt Linux-Containerbereitstellungen.
Bei Verwendung des Premium-Plans werden Instanzen des Azure Functions-Hosts basierend auf der Anzahl der eingehenden Ereignisse hinzugefügt und entfernt, wie es auch beim Verbrauchsplan der Fall ist. Mehrere Funktions-Apps können im selben Premium-Plan bereitgestellt werden, und der Tarif ermöglicht es Ihnen, die Compute-Instanzgröße, Basisplangröße und maximale Plangröße zu konfigurieren.
Abrechnung
Die Abrechnung für den Premium-Plan basiert auf der Anzahl von Kernsekunden und dem Arbeitsspeicher, der den Instanzen zugeordnet ist. Diese Abrechnung unterscheidet sich vom Verbrauchsplan, der basierend auf dem Ressourcenverbrauch und den Ausführungen pro Sekunde abgerechnet wird. Beim Premium-Plan fallen keine Gebühren pro Ausführung an. Diese Abrechnung führt zu monatlichen Mindestkosten pro aktivem Plan, unabhängig davon, ob die Funktion aktiv oder im Leerlauf ist. Beachten Sie, dass sich alle Funktions-Apps in einem Premium-Plan die zugeordneten Instanzen teilen. Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Azure Functions.
Hinweis
Jeder Premium-Plan bietet immer mindestens eine aktive (in Rechnung gestellte) Instanz.
Erstellen eines Premium-Plans
Wenn Sie eine Funktions-App im Azure-Portal erstellen, gilt standardmäßig der Verbrauchsplan. Wenn Sie eine Funktions-App erstellen möchten, die in einem Premium-Plan ausgeführt wird, müssen Sie unter Verwendung einer der Elastic Premium-SKUs explizit einen Premium-Hostingplan für Azure Functions erstellen. Die von Ihnen erstellte Funktions-App wird dann in diesem Plan gehostet. Im Azure-Portal können Sie den Premium-Plan und die Funktions-App ganz einfach gleichzeitig erstellen. Sie können mehrere Funktions-Apps im selben Premium-Plan ausführen, aber nur, wenn alle Apps unter demselben Betriebssystem (Windows oder Linux) ausgeführt werden.
In den folgenden Artikeln erfahren Sie, wie Sie programmgesteuert eine Funktions-App mit einem Premium-Plan erstellen:
Vermeiden von Kaltstarts
Wenn Ereignisse oder Ausführungen nicht im Verbrauchsplan vorkommen, kann Ihre Anwendung auf null Instanzen skalieren. Wenn neue Ereignisse eintreffen, muss eine neue Instanz angegeben werden, in der Ihre App ausgeführt wird. Die Spezialisierung neuer Instanzen braucht Zeit, je nach App. Diese zusätzliche Wartezeit beim ersten Aufruf wird häufig als App-Kaltstart bezeichnet.
Der Premium-Plan bietet zwei Funktionen, die zusammenarbeiten, um Kaltstarts in Ihren Funktionen effektiv zu vermeiden: jederzeit bereite Instanzen und vorgewärmte Instanzen. Jederzeit bereite Instanzen sind eine Kategorie von vorab zugewiesenen Instanzen, die von der Skalierung nicht betroffen sind, und die vorgewärmten Instanzen sind ein Puffer, wenn Sie aufgrund von HTTP-Ereignissen skalieren.
Wenn Ereignisse mit dem Auslösen der App beginnen, werden sie zuerst an die jederzeit bereiten Instanzen weitergeleitet. Da die Funktion aufgrund von HTTP-Ereignissen aktiv wird, werden andere Instanzen als Puffer warm. Diese gepufferten Instanzen werden vorgewärmte Instanzen bezeichnet. Dieser Puffer reduziert Kaltstarts für neue Instanzen, die während der Skalierung erforderlich sind.
Jederzeit bereite Instanzen
Im Premium-Plan können Sie Ihre App jederzeit bereit für eine angegebene Anzahl von Instanzen vorhalten. Ihre App wird unabhängig von der Auslastung kontinuierlich auf diesen Instanzen ausgeführt. Wenn die Auslastung die Kapazität Ihrer jederzeit bereiten Instanzen übersteigt, werden bei Bedarf weitere Instanzen bis zu der von Ihnen festgelegten Obergrenze hinzugefügt.
Diese Einstellung auf App-Ebene steuert auch die Mindestanzahl der Instanzen Ihres Plans. Angenommen, Sie verwenden drei Funktions-Apps im gleichen Premium-Plan. Wenn zwei Ihrer Apps immer bereit sind, die Anzahl der Instanzen auf eins und in einer dritten Instanz auf fünf festgelegt ist, beträgt die Mindestanzahl für Ihren gesamten Plan fünf. Dies spiegelt auch die Mindestanzahl der Instanzen wider, die im Rahmen Ihres Plans in Rechnung gestellt werden. Die maximale Anzahl der von uns unterstützten Instanzen beträgt 20.
Sie können die Anzahl der jederzeit bereiten Instanzen im Azure-Portal konfigurieren, indem Sie Ihre Funktions-App auswählen, zur Registerkarte Plattformfeatures wechseln und die Optionen zum Aufskalieren auswählen. Im Bearbeitungsfenster der Funktions-App sind jederzeit bereite Instanzen für diese App spezifisch.
Vorgewärmte Instanzen
Die Einstellung für die Anzahl der vorgewärmten Instanzen bietet vorgewärmte Instanzen als Puffer während HTTP-Skalierungs- und Aktivierungsereignissen. Vorgewärmte Instanzen setzen die Pufferung fort, bis der Grenzwert für maximale horizontale Skalierung erreicht wird. Die standardmäßige Anzahl vorgewärmter Instanzen ist 1, und dieser Wert sollte für die meisten Szenarien beibehalten werden.
Stellen Sie sich ein weniger gängiges Szenario vor, beispielsweise eine App, die in einem benutzerdefinierten Container ausgeführt wird. Da benutzerdefinierte Container eine lange Aufwärmzeit haben, könnten Sie erwägen, diesen Puffer an vorgewärmten Instanzen zu erhöhen. Eine vorgewärmte Instanz wird erst aktiv, wenn alle aktiven Instanzen genutzt werden.
Sie können auch einen Aufwärmtrigger definieren, der vor dem Aufwärmvorgang ausgeführt wird. Ein Trigger für die Aufwärmphase kann verwendet werden, um während der Vorabaufwärmung benutzerdefinierte Abhängigkeiten vorab zu laden, damit Ihre Funktionen sofort mit der Verarbeitung von Anforderungen beginnen können. Weitere Informationen finden Sie unter Azure Functions-Aufwärmtrigger.
Folgendes Beispiel zeigt, wie jederzeit bereite Instanzen und vorgewärmte Instanzen zusammenarbeiten. Für eine Premium-Funktions-App sind zwei jederzeit bereite Instanzen konfiguriert und die Standardeinstellung bietet eine vorgewärmte Instanz.
- Wenn sich die App im Leerlauf befindet und keine Ereignisse als Auslöser vorhanden sind, wird die App mit zwei Instanzen bereitgestellt und ausgeführt. Zu diesem Zeitpunkt werden Ihnen die beiden immer bereiten Instanzen in Rechnung gestellt, nicht aber eine vorgewärmte Instanz, da keine vorgewärmte Instanz zugewiesen ist.
- Wenn Ihre Anwendung den HTTP-Datenverkehr empfängt, werden Anforderungen über die beiden jederzeit bereiten Instanzen geladen. Sobald diese beiden Instanzen die Verarbeitungsereignisse starten, wird eine Instanz hinzugefügt, um den vorgewärmten Puffer zu füllen. Die Anwendung läuft jetzt mit drei bereitgestellten Instanzen: Die beiden jederzeit bereiten Instanzen und der dritte vorgewärmte und inaktive Puffer. Ihnen werden die drei Instanzen in Rechnung gestellt.
- Wenn die Last erhöht wird und Ihre App mehr Instanzen zum Verarbeiten des HTTP-Datenverkehrs benötigt, wird die vorbereitete Instanz zu einer aktiven Instanz. Die HTTP-Last wird nun an alle drei Instanzen weitergeleitet, und eine vierte Instanz wird sofort bereitgestellt, um den vorgewärmten Puffer zu füllen.
- Diese Abfolge von Skalierung und Vorwärmen wird fortgesetzt, bis die maximale Anzahl von Instanzen für die Anwendung erreicht ist oder die Last abnimmt, sodass die Plattform nach einer gewissen Zeit wieder skaliert. Es werden keine Instanzen vorgewärmt oder über das Maximum hinaus aktiviert.
Sie können die Einstellung für die Anzahl der vorgewärmten Instanzen nicht über das Portal ändern, sondern müssen stattdessen die Azure CLI oder die Azure PowerShell verwenden.
Maximale Anzahl von Funktions-App-Instanzen
Zusätzlich zur maximalen Anzahl von Bursts des Plans können Sie einen maximale Anzahl pro App konfigurieren. Die maximale Anzahl pro App kann mit der App-Skalierungsgrenze konfiguriert werden. Der maximale Grenzwert für die horizontale Skalierung der App darf die Höchstzahl von Burstinstanzen des Plans nicht überschreiten.
Private Netzwerkkonnektivität
Funktions-Apps, die in einem Premium-Plan bereitgestellt wurden, können von der VNet-Integration für Web-Apps profitieren. Wenn Ihre Anwendung konfiguriert ist, kann sie mit Ressourcen innerhalb Ihres virtuellen Netzwerks oder über gesicherte Dienstendpunkte kommunizieren. IP-Einschränkungen sind ebenfalls für die App verfügbar, um eingehenden Datenverkehr zu beschränken.
Wenn Sie Ihrer Funktions-App in einem Premium-Plan ein Subnetz zuweisen, benötigen Sie ein Subnetz mit genügend IP-Adressen für jede mögliche-Instanz. Wir benötigen einen IP-Block mit mindestens 100 verfügbaren Adressen.
Weitere Informationen finden Sie unter Integrieren einer Funktions-App in ein virtuelles Netzwerk.
Schnelle elastische Skalierung
Weitere Compute-Instanzen werden automatisch für Ihre Anwendung hinzugefügt, wobei dieselbe schnelle Skalierungslogik wie beim Verbrauchsplan angewendet wird. Apps im gleichen App Service-Plan werden unabhängig voneinander auf der Grundlage der Anforderungen der jeweiligen App skaliert. Von Funktions-Apps im gleichen App Service-Plan werden VM-Ressourcen jedoch nach Möglichkeit gemeinsam genutzt, um Kosten zu sparen. Die Anzahl von Apps, die einem virtuellen Computer zugeordnet sind, hängt vom Speicherbedarf der einzelnen Apps sowie von der Größe des virtuellen Computers ab.
Informationen zur Funktionsweise der Skalierung finden Sie unter Ereignisgesteuerte Skalierung in Azure Functions.
Längere Ausführungsdauer
Funktionen in einem Verbrauchstarif sind auf 10 Minuten für eine einzelne Ausführung beschränkt. Im Premium-Plan wird die Ausführungsdauer standardmäßig auf 30 Minuten festgelegt, um Endlosausführungen zu verhindern. Sie können jedoch die Konfiguration in „host.json“ ändern, um die Dauer für Apps im Premium-Tarif auf unbegrenzt festzulegen. Datei gelten jedoch die folgenden Einschränkungen:
- Plattformupgrades können ein verwaltetes Herunterfahren auslösen und die Ausführung der Funktion mit einer Toleranzperiode von 10 Minuten beenden.
- Es gibt einen Leerlaufzeitgeber, der den Worker nach 60 Minuten ohne neue Ausführung beendet.
- Das Skalierungsverhalten kann dazu führen, dass der Worker nach 60 Minuten heruntergefahren wird.
- Slotwechsel können Ausführungen in den Quell- und Zielslots während des Wechsels beenden.
Migration
Wenn Sie über eine vorhandene Funktions-App verfügen, können Sie Azure CLI-Befehle verwenden, um Ihre App unter Windows zwischen einem Verbrauchsplan und einem Premium-Plan zu migrieren. Die spezifischen Befehle hängen von der Richtung der Migration ab. Weitere Informationen finden Sie unter Planmigration.
Die Migration wird unter Linux nicht unterstützt.
Einstellungen für Premium-Pläne
Wenn Sie den Plan erstellen, konfigurieren Sie zwei Einstellungen für die Plangröße: die Mindestanzahl von Instanzen (oder Plangröße) und den maximalen Burstgrenzwert.
Wenn Ihre App über die jederzeit bereiten Instanzen hinaus weitere Instanzen benötigt, kann das horizontale Skalieren fortgesetzt werden, bis die Anzahl das maximale Burstlimit oder – wenn konfiguriert – das maximale Limit für die horizontale Skalierung erreicht. Instanzen werden Ihnen nur in Rechnung gestellt, während sie ausgeführt werden und Ihnen zugeordnet sind. Die Abrechnung erfolgt sekundengenau. Die Plattform versucht, Ihre App bis zu den definierten Maximalwerten zu skalieren.
Sie können die Plangröße und die Maximalwerte im Azure-Portal konfigurieren, indem Sie die Optionen für Aufskalieren unter Einstellungen einer Funktions-App auswählen, die für diesen Plan bereitgestellt ist.
Das Minimum für jeden Premium-Plan liegt bei mindestens einer Instanz. Die tatsächliche Mindestanzahl an Instanzen wird für Sie auf der Grundlage der von den Anwendungen im Plan angeforderten immer bereiten Instanzen bestimmt. Wenn z. B. Anwendung A fünf ständig verfügbare Instanzen anfordert und Anwendung B zwei ständig verfügbare Instanzen im selben Plan anfordert, wird die Mindestplangröße auf fünf festgelegt. Anwendung A wird auf allen fünf ausgeführt, und Anwendung B wird nur auf 2 ausgeführt.
Wichtig
Ihnen wird jede Instanz, die entsprechend der Mindestanzahl von Instanzen zugeordnet ist, in Rechnung gestellt, unabhängig davon, ob Funktionen ausgeführt werden oder nicht.
In den meisten Fällen ist dieser automatisch berechnete Mindestwert ausreichend. Eine Skalierung über den Mindestwert hinaus erfolgt jedoch nach bestem Bemühen. Es ist möglich, wenn auch unwahrscheinlich, dass sich die horizontale Skalierung zu einem bestimmten Zeitpunkt verzögert, wenn andere Instanzen nicht verfügbar sind. Wenn Sie einen Mindestwert festlegen, der höher als der automatisch berechnete Mindestwert ist, reservieren Sie Instanzen vor dem horizontalen Hochskalieren.
Sie können die Mindestanzahl von Instanzen im Azure-Portal konfigurieren, indem Sie die Optionen für Aufskalieren unter Einstellungen einer Funktions-App auswählen, die für diesen Plan bereitgestellt ist.
Verfügbare Instanz-SKUs
Wenn Sie Ihren Plan erstellen oder skalieren, können Sie zwischen drei Instanzgrößen wählen. Die Abrechnung erfolgt für die Gesamtzahl der Kerne und des Arbeitsspeichers, die Ihnen pro Sekunde für jede Instanz zur Verfügung gestellt werden. Ihre App kann automatisch nach Bedarf auf mehrere Instanzen aufskaliert werden.
| SKU | Kerne | Arbeitsspeicher | Storage |
|---|---|---|---|
| EP1 | 1 | 3,5 GB | 250 GB |
| EP2 | 2 | 7 GB | 250 GB |
| EP3 | 4 | 14 GB | 250 GB |
Überlegungen zur Speicherauslastung
Das Ausführen auf einem Computer mit mehr Arbeitsspeicher bedeutet nicht immer, dass Ihre Funktions-App den gesamten verfügbaren Arbeitsspeicher auch verwendet.
Beispielsweise wird eine JavaScript-Funktions-App durch das standardmäßige Arbeitsspeicherlimit in „Node.js“ eingeschränkt. Um dieses feste Arbeitsspeicherlimit zu erhöhen, fügen Sie die App-Einstellung languageWorkers:node:arguments mit dem Wert --max-old-space-size=<max memory in MB> hinzu.
Und für Pläne mit mehr als 4 GB Speicher stellen Sie sicher, dass die Bitness-Plattform-Einstellung unter 64 BitAllgemeine Einstellungen auf gesetzt ist.
Maximale horizontale Skalierung der Region
Dies sind die derzeit unterstützten maximalen horizontalen Steuerungswerte für einen einzelnen Plan in jeder Region und Betriebssystemkonfiguration:
| Region | Windows | Linux |
|---|---|---|
| Australien, Mitte | 100 | 20 |
| Australien, Mitte 2 | 100 | Nicht verfügbar. |
| Australien (Osten) | 100 | 40 |
| Australien, Südosten | 100 | 20 |
| Brasilien Süd | 100 | 20 |
| Kanada, Mitte | 100 | 100 |
| Indien, Mitte | 100 | 20 |
| USA (Mitte) | 100 | 100 |
| China, Osten 2 | 20 | 20 |
| China, Norden 2 | 20 | 20 |
| China, Norden 3 | 20 | 20 |
| Asien, Osten | 100 | 20 |
| East US | 100 | 100 |
| USA (Ost) 2 | 80 | 100 |
| Frankreich, Mitte | 100 | 60 |
| Deutschland, Westen-Mitte | 100 | 20 |
| Israel, Mitte | 100 | 20 |
| Italien, Norden | 100 | 20 |
| Japan, Osten | 100 | 20 |
| Japan, Westen | 100 | 20 |
| Jio Indien, Westen | 100 | 20 |
| Korea, Mitte | 100 | 20 |
| Korea, Süden | 40 | 20 |
| Mexiko, Mitte | 20 | 20 |
| USA Nord Mitte | 100 | 20 |
| Nordeuropa | 100 | 100 |
| Norwegen, Osten | 100 | 20 |
| Südafrika, Norden | 100 | 20 |
| Südafrika, Westen | 20 | 20 |
| USA Süd Mitte | 100 | 100 |
| Indien (Süden) | 100 | Nicht verfügbar. |
| Asien, Südosten | 100 | 20 |
| Spanien, Mitte | 20 | 20 |
| Schweiz, Norden | 100 | 20 |
| Schweiz, Westen | 100 | 20 |
| Vereinigte Arabische Emirate, Norden | 100 | 20 |
| UK, Süden | 100 | 100 |
| UK, Westen | 100 | 20 |
| US Gov Arizona | 20 | 20 |
| US Gov Texas | 20 | Nicht verfügbar |
| US Government, Virginia | 80 | 20 |
| USA, Westen-Mitte | 100 | 20 |
| Europa, Westen | 100 | 100 |
| Indien, Westen | 100 | 20 |
| USA (Westen) | 100 | 100 |
| USA, Westen 2 | 100 | 20 |
| USA, Westen 3 | 100 | 20 |
Weitere Informationen finden Sie in der vollständigen regionalen Verfügbarkeit von Azure Functions.