Autoscaling und Failover

Skaliere Web-Replikas nach Last oder nach Zeitplan, und wechsle automatisch auf einen anderen Server.

Autoscaling

App → Settings → General → Autoscaling. Lege eine Mindest- und eine Höchstzahl von Web-Replikas fest; Railyard fügt dazwischen Replikas hinzu oder entfernt sie, basierend auf CPU und p95-Antwortzeit.

Target CPU / replica (%) und das p95-Ziel entscheiden, wann hochskaliert wird.
Replikas teilen sich den Server der App, das hilft also bei CPU-gebundener oder langsamer Request-Last, nicht bei einem vollen Server. Es wird nie hochskaliert, während der Arbeitsspeicher des Servers hoch ist.
Lass Max leer, um eine feste Anzahl von Replikas laufen zu lassen (kein reaktives Scaling).

API: PATCH /api/applications/:id/autoscale mit min, max, cpu, p95_ms.

Geplante Fenster

Scheduled windows heben die Untergrenze vor einem bekannten Peak an, eine Zeile pro Fenster: mon,tue,wed,thu,fri 08:00-18:00 3 (Tage, Start-Ende, Mindestanzahl Replikas, in der Zeitzone der App). Sie wärmen nur vor, während Max gesetzt ist — die üblichen CPU/p95-Regeln entscheiden weiterhin über den Rest, und sie heben nur die Untergrenze während des Fensters an. Nur im Dashboard, noch nicht in API oder CLI.

Failover

Im Servers-Tab einer App füge einen zusätzlichen Server hinzu und aktiviere Fail over automatically: Der Traffic wird auf alle Online-Server verteilt, und wenn der primäre Server für einige Minuten nicht mehr antwortet, wird ein zusätzlicher Server zum primären und die App wird dort neu deployt. Railyard bevorzugt einen zusätzlichen Server in einer anderen Region gegenüber einem in derselben Region.

Falls der Server auch die Daten der App gehalten hat, befördert Railyard einen aktiven Standby (siehe Datenbank-Server) und richtet die App als Teil des Failovers darauf aus. Jede Domain, die der App gehört, wird sofort auf den neuen Server umgestellt, nicht erst beim nächsten Deploy; die eigene DNS einer benutzerdefinierten Domain muss trotzdem folgen, wenn sie nicht auf Railyards verwaltetem DNS liegt. Du wirst benachrichtigt, wenn es passiert.

Ein Datenbank-Server mit einem Standby failover automatisch selbst, egal ob seine Apps zusätzliche Server haben: Der Standby übernimmt die Daten, und jede App, die ihn nutzt, wird gegen ihn neu deployt.

Nur im Dashboard, noch nicht in API oder CLI.