Werkslogistik in der Cloud. Vom Tor bis zur Rampe. – Methodik / Method ===================================================================== DEUTSCH Was zu sehen ist Ein fiktives Werk als weißes Architekturmodell und neben seinem Tor die drei Rechenzentren einer Plattform aus Diensten. Im Modell stehen die Rechenzentren vergrößert neben dem Tor; in Wirklichkeit liegen sie Kilometer entfernt, und jedes ist eine eigene Verfügbarkeitszone. Der Betrieb ist simuliert: Es gibt keine Live-Anbindung, keine echten Fahrzeuge und keine echten Daten. Die Architektur ist exemplarisch und anbieterneutral; sie nennt keine Produkte. Alles läuft im Browser. Werk und Fahrzeuge - Sattelzüge mit 16,5 m Länge, 2,55 m Breite und 4,0 m Höhe (EU-Grenzen). Die Fahrwege halten einen Wendekreis von 12,5 m außen ein. - Zufahrt mit Vorstauspur für fünf Lkw, Kamerabrücke und Schranke, vier Pufferstellplätze, 16 Rampen und eine eigene Ausfahrt. - Die Lkw fahren nur auf Fahrwegen; rückwärts an die Rampe steuert die Zugmaschine, der Auflieger folgt seiner Kinematik. Ein Lkw beginnt eine Fahrt erst, wenn sein ganzer Weg frei ist; er wartet nie auf der Fahrbahn. Eine Prüfung über den ganzen Tag stellt sicher, dass sich keine zwei Lkw berühren. Ablauf (Annahmen) - Die Lkw buchen Zeitfenster und kommen bis zu zehn Minuten früher oder später; 15 % verspäten sich um bis zu weitere 30 Minuten. Gebucht sind etwa 280 Lkw am Tag mit Wellen zur Früh- und Spätschicht (bis 30 je Stunde). - An der Kamerabrücke beginnt die Torprüfung: sechs Bildprüfungen, eine je Kamera, zu je 4 Sekunden Rechenzeit; sie laufen parallel. Danach bestätigt die Slotplanung, die Schranke öffnet, die Rampenzuteilung wählt die Rampe oder den Pufferplatz mit dem frühesten freien Weg, die Benachrichtigung schickt dem Fahrer die Rampe. - Wareneingang: Jede Palette (26 bis 33 je Lkw) wird beim Entladen an der Rampe gescannt und auf der Plattform gebucht, je Buchung 18 Sekunden Rechenzeit. Torprüfungen haben Vorrang vor Buchungen. Ein Lkw fährt erst ab, wenn alle seine Paletten gebucht sind; stauen sich die Buchungen, bleibt er an der Rampe stehen. - Lkw ohne Zeitfenster (Lastspitze) brauchen am Tor die vollständige Prüfung aller 24 Bilder. - Jeder Lkw im Werk meldet sich alle vier Minuten aus dem Hof (Position, Rampensensor); die Rampenzuteilung verarbeitet diese Ereignisse. - Entladen dauert 18 bis 48 Minuten, im Mittel 30 Minuten. Plattform (Annahmen) - Vier Dienste laufen als Instanzen in drei Verfügbarkeitszonen, je Zone in einem Rechenzentrum. Jedes Schrankpaar ist ein Platz für eine Instanz eines Dienstes (vorn sechs für die Torprüfung, dahinter je zwei für Slotplanung, Rampenzuteilung und Benachrichtigung, hinten der Datenspeicher). Eine laufende Instanz heißt hier vereinfacht Server: Ihre Schränke leuchten in der Farbe des Dienstes. Leuchtende Server arbeiten, matte sind bereit, dunkle Schränke sind freie Kapazität. Beim Start steigt das Licht in den Schränken auf. - Cloud-native: Ein Autoscaler hält die Auslastung der Instanzen für Tor und Wareneingang bei etwa 50 %. Er rechnet mit der größeren von zwei Lasten: der der letzten fünf Minuten und der, die die gebuchten Zeitfenster der nächsten 20 Minuten bringen; dazu kommt wartende Arbeit. Mindestens eine, höchstens sechs Instanzen je Zone. Neue Instanzen sind nach 45 Sekunden bereit. Abgebaut wird erst, wenn die Last zehn Minuten lang darunter bleibt, dann eine Instanz je drei Minuten. - Feste Kapazität: dieselben Lkw, aber immer eine Instanz für Tor und Wareneingang je Zone, ausgelegt auf die mittlere Last des Tagbetriebs (06 bis 18 Uhr gut drei voll ausgelastete Instanzen), und kein Ersatz, wenn eine Zone ausfällt. In den Wellen stauen sich die Buchungen, Lkw warten an den Rampen, und der Rückstau erreicht das Tor: im Standardlauf bis 11 Lkw am Vormittag und bis 16 am Nachmittag, bei Cloud-native höchstens 2. - Kosten: Das HUD der Plattform zeigt die Serverstunden des Tages für Tor und Wareneingang im gezeigten Betrieb mit dem größten Vorstau bis dahin. Unter dem Verlaufsdiagramm stehen alle drei nebeneinander: Cloud-native, feste Kapazität für die Mittellast und eine feste Kapazität für die geplante Spitze des Standardtags (12 Server, ohne ausgelöste Lastspitzen). Serverstunden zählen ab dem Start eines Servers, denn auch die Anlaufzeit kostet; als laufende Server im HUD zählen dagegen nur bereite, startende stehen daneben (+1 startet). Über den Tag: Cloud-native 135 Serverstunden bei höchstens 2 Lkw Vorstau; fest für die Mittellast 72 Serverstunden, aber bis 16 Lkw Vorstau; fest für die geplante Spitze 288. Cloud-native hält etwa die Hälfte Reserve (Ziel 50 % Auslastung) und braucht trotzdem rund die Hälfte der Serverstunden einer Auslegung auf die Spitze. - Als Vorstau zählen Lkw in der Vorstauspur und solche, die weiter hinten auf der Straße warten; ein Lkw, der noch auf der Straße zu seinem Platz fährt, zählt erst, wenn er dort ankommt. - Lkw, die länger als drei Minuten im Vorstau stehen oder entladen an der Rampe auf offene Buchungen warten, tragen im Bild eine orange Raute über der Kabine. - Zonenausfall: Der geplante Ausfall trifft Zone B um 13:52 in beiden Betriebsarten zur selben Zeit, für 30 Minuten. Eine Zone fällt nur einmal zur selben Zeit aus. Die Instanzen der Zone fallen weg; die Plattform erkennt den Ausfall nach 30 Sekunden (Health Checks) und startet erst dann Ersatz, die Serverzahl sinkt also kurz. Ihre laufenden Aufgaben gehen zurück in die Warteschlange und werden wiederholt. Das HUD zählt wiederholte Aufgaben und verlorene, also solche, die weder erledigt sind noch warten noch laufen; im Standardlauf sind es 3 wiederholte und 0 verlorene. Bei Cloud-native starten die übrigen Zonen Ersatz, bei fester Kapazität nicht. - Die Zahlen sind eine Annahme, gewählt, damit Skalierung und Ausfall sichtbar werden. Sie sagen nichts über reale Systeme aus. Zeitraffer Die Frühschicht beginnt in der Zeitleiste um 06:39, der Tagbetrieb um 08:30; während in der Frühschicht ein Server startet, läuft der Zeitraffer 20-fach. Der simulierte Tag läuft im Zeitraffer: 30-fach in der Frühschicht, 60-fach am Tag und ab der Störung, 240-fach in der Nacht ab 21 Uhr. Um einen Zonenausfall herum läuft er 10-fach. Die Ansicht Ende-zu-Ende nimmt den nächsten Lkw vor der Kamerabrücke auf, sonst einen auf dem Weg zur Rampe; sie fährt 15-fach mit, solange er fährt, 120-fach, solange sie auf ihn wartet, und 240-fach, während er an der Rampe steht, und begleitet ihn bis zur Ausfahrt. Die Simulation läuft nach der Uhr, nicht nach der Bildrate des Bildschirms. ENGLISH What you see A fictional plant as a white architectural model, and next to its gate the three data centres of a platform of services. In the model the data centres stand enlarged next to the gate; in reality they lie kilometres apart, and each is an availability zone of its own. The operation is simulated: there is no live connection, there are no real vehicles and no real data. The architecture is an example and vendor-neutral; it names no products. Everything runs in the browser. Plant and vehicles - Articulated lorries 16.5 m long, 2.55 m wide and 4.0 m high (EU limits). The lanes keep an outer turning circle of 12.5 m. - Access road with a queue lane for five lorries, a camera bridge and a barrier, four buffer stalls, 16 docks and a separate exit. - Lorries drive on lanes only; reversing to a dock, the tractor steers and the trailer follows its kinematics. A lorry starts a move only when its whole path is free; it never waits on a lane. A check over the whole day makes sure that no two lorries touch. Process (assumptions) - Lorries book time slots and arrive up to ten minutes early or late; 15 % are delayed by up to another 30 minutes. About 280 lorries are booked per day, with waves at the early and the late shift (up to 30 per hour). - The gate check starts at the camera bridge: six image checks, one per camera, of 4 seconds of computing time each; they run in parallel. Then slot planning confirms, the barrier opens, dock assignment chooses the dock or buffer stall with the earliest free path, and notification sends the dock to the driver. - Goods receipt: every pallet (26 to 33 per lorry) is scanned at the dock while unloading and booked on the platform, 18 seconds of computing time per booking. Gate checks go ahead of bookings. A lorry leaves only when all its pallets are booked; when bookings back up, it stays at the dock. - Lorries without a time slot (load peak) need the full check of all 24 images at the gate. - Every lorry on site reports from the yard every four minutes (position, dock sensor); dock assignment processes these events. - Unloading takes 18 to 48 minutes, 30 minutes on average. Platform (assumptions) - Four services run as instances in three availability zones, one data centre per zone. Every pair of cabinets is a place for one instance of a service (six at the front for the gate check, behind them two each for slot planning, dock assignment and notification, the data store at the back). A running instance is called a server here, for simplicity: its cabinets glow in the service's colour. Glowing servers are at work, matt ones are ready, dark cabinets are free capacity. While a server starts, the light rises in its cabinets. - Cloud-native: an autoscaler keeps the gate and goods-receipt instances at about 50 % load. It works with the larger of two loads: that of the last five minutes and that which the booked time slots of the next 20 minutes bring, plus waiting work. At least one and at most six instances per zone. New instances are ready after 45 seconds. Instances are removed only after the load has stayed below for ten minutes, then one every three minutes. - Fixed capacity: the same lorries, but always one gate and goods-receipt instance per zone, sized for the mean load of the day shift (06:00 to 18:00, a little over three fully loaded instances), and no replacement when a zone fails. In the waves bookings back up, lorries wait at the docks and the queue reaches the gate: in the standard run up to 11 lorries in the morning and up to 16 in the afternoon, at most 2 with cloud-native. - Cost: the platform HUD shows the day's server hours for the gate and goods receipt in the mode shown with the longest queue so far. Below the course chart all three stand side by side: cloud-native, fixed capacity for the mean load, and a fixed capacity for the planned peak of the standard day (12 servers, without triggered load peaks). Server hours count from a server's start, since the start-up costs too; as running servers the HUD counts only ready ones and names starting ones beside them (+1 starting). Over the day: cloud-native 135 server hours with a queue of at most 2 lorries; fixed for the mean load 72 server hours, but queues of up to 16 lorries; fixed for the planned peak 288. Cloud-native keeps about half in reserve (50 % target load) and still needs about half the server hours of sizing for the peak. - The queue counts lorries in the queue lane and those waiting further back on the road; a lorry still driving along the road to its place counts once it arrives there. - Lorries that stand in the queue for more than three minutes, or wait unloaded at a dock for open bookings, carry an orange diamond above the cab. - Zone failure: the scripted failure hits zone B at 13:52 in both modes at the same time, for 30 minutes. A zone fails only once at a time. The zone's instances are lost; the platform detects the failure after 30 seconds (health checks) and only then starts replacements, so the server count dips briefly. Their running tasks go back to the queue and are retried. The HUD counts retried tasks and lost ones, that is tasks neither done nor waiting nor running; in the standard run 3 are retried and 0 are lost. With cloud-native the other zones start replacements, with fixed capacity they do not. - The figures are assumptions, chosen to make scaling and failure visible. They say nothing about real systems. Time-lapse The early shift starts at 06:39 on the timeline, the day at 08:30; while a server starts in the early shift, the time-lapse runs at 20 times. The simulated day runs in time-lapse: 30 times in the early shift, 60 times during the day and from the outage on, 240 times at night from 21:00. Around a zone failure it runs 10 times. The end-to-end view takes up the next lorry before the camera bridge, else one on its way to a dock; it rides along at 15 times while the lorry moves, at 120 times while it waits for it and at 240 times while the lorry stands at the dock, and follows it to the exit. The simulation runs by the clock, not by the frame rate of the screen.