Instance Scheduler

Warum es verwenden

Entwicklungs-, Test- und Staging-Server werden häufig nur während der Arbeitszeit genutzt, sind jedoch alle 168 Stunden der Woche in Betrieb (und werden in Rechnung gestellt). Ein Server, der montags bis freitags von 8:00 bis 19:00 Uhr läuft, benötigt 55 dieser Stunden, sodass etwa zwei Drittel seiner Rechenkosten vermeidbar sind. Die Seite zeigt die Ersparnis für die eigenen Server und beruht nicht auf einer pauschalen Aussage.

Die eine Schreibberechtigung und wie man sie ausschaltet

Erstellen Sie einen Zeitplan

A schedule is a named set of hours, such as “Weekdays 08:00-19:00”. You make it once and apply it to any number of servers, directly or through a tag policy. Changing the schedule changes everything that follows it.

Switch a schedule off on its card to pause every server that follows it, and switch it on to resume. Servers are left running while it is paused. To stop scheduling one server, open it and choose Remove schedule; the server is left in whatever state it is in.

Was passiert als nächstes?

Ein Job wird ausgeführt every 30 minutes. Für jeden aktivierten Zeitplan ermittelt es anhand der Zeitzone, ob der Server gerade laufen oder gestoppt werden soll, vergleicht dies mit dem tatsächlichen Zustand und startet oder stoppt ihn, wenn sie abweichen. Because it checks the desired state every 30 minutes rather than firing at an exact minute, a missed run corrects itself on the next one. The practical effect: a start or stop happens within 30 minutes after the time you set.

Verschiedene Arten von Zielen

So lesen Sie die Seite

Schedule by tag

A tag policy says “everything tagged env=dev follows Weekdays 08:00-19:00”. Open the Tag policies tab and choose New tag policy: name it, pick the tag key and whether the value must equal or start with your text (leave the value empty to match any value), choose the schedule and the clouds. The preview lists exactly what it would schedule and what it would skip, with the reason. Saving creates ordinary schedules for the matching resources, so they appear in the list marked with the policy name and behave like any other schedule.

• Order matters. Policies are numbered; if several match a resource, the first one wins. Use the arrows to move a policy up or down.
• Tag keys and values are not case sensitive. A bad value (a date that is not a date, an unknown timezone, only one of the two date tags) is ignored and flagged on the page, so a typo never schedules the wrong thing.
• New and re-tagged resources are picked up on the next check after discovery. A resource that loses its tag is released, and started again first if the scheduler had stopped it.
• A schedule you made by hand on a resource always wins; a policy never changes it (a tag stop window is still added to it).
• Pausing a schedule pauses the policies that use it, and the policy shows Schedule paused. A schedule that a policy or server uses cannot be deleted.
• Resources that cannot be scheduled (group members, Kubernetes nodes, databases the provider cannot stop, connections without the scheduler permission) are skipped, and the preview says why.
• Exclude from policy on a resource stops the policy managing it. Deleting a policy removes its schedules and starts anything it had stopped.
• Saving a policy changes nothing in your cloud by itself. The next scheduler check does, and it stops anything outside the window at that moment.

Stop dates and public holidays

Besides its weekly schedule, a VM, scaling group or database can have any number of stop dates: whole days it stays stopped, such as a year-end shutdown or the public holidays of the office’s country. Open the resource, then Open calendarunder the schedule. Click the first and last day, add an optional label, and Add dates; Save stop dates stores them.

• The days are in the schedule’s timezone, first and last day included. On those days the target is stopped whatever the weekly schedule says; on every other day the weekly schedule applies.
• A target with no weekly schedule can have stop dates only: it runs outside them and is stopped inside them.
• The calendar suggests the public holidays of the country the timezone belongs to (for example Europe/London → United Kingdom, England). Change the country or region, tick the holidays you want, or add all the upcoming ones. A holiday that falls on a day the weekly schedule is already off changes nothing.
• Dates that come from cg-stop-from / cg-stop-to tags show as “from tags” and cannot be edited in the calendar; change the tag instead.
• Stop dates that have passed are removed automatically. Holiday data comes from an open-source holiday library and can differ from your company’s own calendar, so check the list before saving.
• Stop dates stop the target at the first scheduler check on the first day (which may be a few minutes after midnight) and start it again at the check after the last day ends, if the weekly schedule says it should be running.

Resources that look like production

A resource whose name contains the word Produkt, prd, Produktion oder live (as a word, so “web-prd-01” counts but “product-catalog” does not), or whose env / Umfeld / stage tag says so, is marked PROD? in red in the list. Before you create or change a schedule or add stop dates for one, a red notice names it and you must tick a box accepting responsibility; the save is refused without it, and the audit log records that you accepted.

• A tag policy that would cover such resources shows the same notice with their names in the preview. Once you accept it, the policy includes production-looking resources; until then it skips them and says why.
• Pausing a policy or removing stop dates needs no acceptance.
• This is a name and tag check, not a guarantee. A production resource with an unrelated name is not flagged, so you stay responsible for what you schedule. Resources scheduled by cg-stop-from / cg-stop-to tags are not checked, because setting the tag in your cloud is the explicit action.

Shutdown warnings and delay links

The scheduler can warn you before it stops something. Under Shutdown warnings (the bell at the top of the Instance Scheduler page), switch warnings on, add one or more email, Slack or Microsoft Teams channels, and choose how far ahead to warn. Each warning names the resource, the stop time in its own timezone, the rule behind it and who created it, with buttons to delay the shutdown by 1 hour, 2 hours, 3 hours or for the rest of the day.

• A button opens a confirmation page and changes nothing until you press confirm there (mail scanners and chat apps open links automatically, so a click alone never applies a delay).
• A delay counts from the planned stop time; “for the day” runs to midnight in the schedule’s timezone. The normal schedule resumes afterwards, and you get another warning before the new stop.
• Warnings are checked each time the scheduler runs (every 30 minutes), so one arrives up to 30 minutes or more ahead, never later than the stop. Choose a longer lead time to be warned earlier.
• The person who created each schedule can also be emailed. For tag policies that is the person who created the policy.
• If many resources stop at once, the first ten get their own warning with delay links; the rest are listed in one summary that links to the page, where you can delay each of them.
• A delay is refused if the target has already stopped. Starting it again is done from the page after signing in.
• Links are signed and expire two hours after the stop time. Anyone who receives a warning can use its links, so every delay is recorded in the audit log as made through a notification link, with the new end time, rather than under a person’s name.

Who created a schedule (audit trail)

Every change is written to the audit log under Settings → Audit log with the person who made it: schedules created, changed, removed or excluded from a policy, stop dates added or removed, manual starts and stops, and tag policies created, edited, paused or deleted. Changes CostGlass makes by itself are recorded with the source System and say why (the tag policy, or the tags on the resource).

• The schedule editor shows how the schedule was set up, who created it and who last changed it.
• Each start or stop in the activity feed ends with the rule that caused it and who or what set that rule up, so a target that was stopped by mistake can be traced to a person, a policy or a tag.
• For schedules that come from cg- tags CostGlass cannot see who set the tag in your cloud. Check your cloud’s own audit log (CloudTrail, Azure Activity Log, Cloud Audit Logs).

Risiken und bewährte Verfahren

• Databases: a stop ends the compute charge only, connections are dropped, and an application that cannot reconnect after the morning start will fail. Test on one non-critical database first.
• Überprüfen Sie, was beim Booten startet. Ein Server, der nach einem Neustart manuelle Schritte erfordert, wird morgens kaputt gehen.
• Öffentliche IP-Adressen können sich ändern, wenn eine EC2-Instanz gestoppt und gestartet wird, es sei denn, Sie verwenden eine elastische IP.
• Sagen Sie es dem Team. Fügen Sie den Zeitplan Ihrem Runbook hinzu, damit sich niemand wundert, warum ein Server ausgeschaltet ist.
• Lassen Sie Produktionsserver ungeplant, es sei denn, Sie haben einen bewussten Grund.
• Bevorzugen Sie Zeitpläne für Auto Scaling-Gruppen für Flotten, damit die eigene Skalierung der Gruppe nicht gestört wird.
• Reservierte Kapazität und Sparpläne werden unabhängig davon bezahlt, ob der Server läuft oder nicht. Durch das Stoppen eines abgedeckten Servers wird kein Geld für den abgedeckten Teil gespart (siehe Commitments (Sparverpflichtungen)).

Häufig gestellte Fragen

Verwandte Anleitungen