Zusammenfassung

  • Merakis historisches Beispiel C ergänzt zwei einjährige Switch-Lizenzen und verschiebt den gemeinsamen Ablauf vom 16. April auf den 14. März 2017: 33 Tage nach vorn.
  • Co-Term gewichtet Lizenzmengen und Laufzeiten nach Lizenztyp. Geräteabbau, zusätzliche Lizenzen und Verlängerung greifen an unterschiedlichen Stellen dieses Systems ein.

Der alte Switch ist ausgebaut. Sein Eintrag verschwindet aus dem Netz. Der gemeinsame Lizenztermin rührt sich keinen Tag. Wer von einem Cloud-Dienst erwartet, dass weniger benutzte Hardware automatisch mehr Restlaufzeit ergibt, stößt bei Merakis Co-Term auf eine andere Buchführung: Der Kalender folgt dem Lizenzbestand.

Die Co-Term-Dokumentation sagt das ausdrücklich. Maßgeblich sind die Lizenzlimits, nicht die gegenwärtige Zahl der Geräte. Das Entfernen eines Geräts aus einem Netzwerk oder einer Organisation verändert den Ablauftermin nicht. Die Hardware kann längst im Regal liegen, während ihr ehemaliger Betreiber noch mit derselben gemeinsamen Frist plant.

Interessanter wird die Rechnung beim Einkauf. Eine neue Lizenz kann den gemeinsamen Termin sogar vorziehen. Mehr abgedeckte Geräte und mehr Zeit bis zur nächsten Verlängerung sind zwei verschiedene Ergebnisse derselben Bestellung.

Die 33 Tage stehen beim Hersteller

Im offiziellen Beispiel C zur Co-Term-Berechnung bleiben einer Organisation am 31. März 2015 noch 747 Tage. Hinzu kommen zwei MS42P-Switches mit je einer einjährigen Lizenz. Die veröffentlichte Rechnung endet bei 714 Tagen Restlaufzeit. Aus dem 16. April 2017 wird der 14. März 2017.

Das historische Lehrbeispiel nimmt damit 33 Tage aus dem bisherigen Kalender. Seine Aussage liegt in der Zusammenführung der Laufzeiten. Die neuen 365 Tage sind kürzer als die 747 Tage, die der bisherige Bestand noch hat. Unter einem gemeinsamen Enddatum zieht diese kurze Ergänzung den gewichteten Durchschnitt nach unten.

Co-Term führt die Lizenzen einer Meraki-Organisation auf einen gemeinsamen Ablauftermin. Eine solche Organisation ist die administrative Gruppierung im Dienst. Für sie werden alte und neue Lizenzen mit ihren Mengen und Zeitanteilen zusammen betrachtet.

Dabei zählt zusätzlich der Lizenztyp. Die ausführliche Erklärung verwendet dessen Einjahreslistenpreis als Gewicht, den sogenannten Base Price. Das ist eine Rechengröße des Lizenzmodells. Der tatsächlich ausgehandelte Rechnungsbetrag steht in einer anderen Rechnung, nämlich der des Einkaufs.

Bei neu hinzukommenden Geräten beginnt der Zeitbeitrag mit der neuen Laufzeit abzüglich der vorhandenen Restlaufzeit. Ist die neue Laufzeit kürzer, entsteht ein negativer Beitrag. Über die Gewichte des vollständigen Lizenzpools wird daraus die Veränderung des gemeinsamen Termins. So erklärt sich die Richtung der 33 Tage, ohne aus historischen Listenpreisen ein heutiges Angebot zu basteln.

Der intuitive Denkfehler ist ein eigener kleiner Kalender pro Bestellung. Im gewählten Modell tritt die Bestellung stattdessen einem vorhandenen Kalender bei. Die Filiale erhält ihre zusätzlichen Lizenzen; die übrige Organisation erhält einen neuen gemeinsamen Termin gleich mit.

Drei Zahlen, die keine Stellvertreter sind

Die aktuelle Gerätezahl beschreibt Geräte, die Netzwerken der Organisation hinzugefügt sind. Ein Gerät allein im Inventar zählt dafür noch nicht. Das Lizenzlimit beschreibt die geltende lizenzierte Kapazität. Die Restlaufzeit beschreibt den zeitlichen Zustand des gemeinsamen Bestands.

Keine dieser Zahlen kann die beiden anderen zuverlässig ersetzen. Weniger aktive Geräte können einen Mengenüberhang beseitigen, ohne den Termin zu verändern. Eine längere Laufzeit auf einer neuen Lizenz sagt für sich allein noch nichts über die Kapazität aus, die ein Verlängerungsschlüssel abdeckt. Und ein voller Lagerraum hält eine bereits laufende Lizenz nicht an.

Meraki beschreibt den Beginn der Laufzeit mit der Verarbeitung der Lizenz. Sie erst später in Dashboard einzutragen verschiebt diesen Beginn nicht. Der Plan, den Schlüssel bis zur Inbetriebnahme aufzubewahren und dadurch Zeit zu gewinnen, geht nach dieser Regel leer aus.

Eine Verlängerung kann zu klein werden

Beim Eintragen unterscheidet Meraki zwischen dem Hinzufügen weiterer Geräte und einer Verlängerung. Die technische Erläuterung verwendet bei einer reinen Verlängerung die volle neu gekaufte Laufzeit. Bei zusätzlichen Geräten geht die schon vorhandene Restlaufzeit in den inkrementellen Beitrag ein. Wer beides als identische Eingabe behandelt, erwartet am falschen Ende der Rechnung dasselbe Ergebnis.

Die Option „Renew my Dashboard license“ setzt außerdem die lizenzierten Gerätemengen auf die Mengen des neuen Schlüssels. Die Übersicht illustriert das mit fünf Access Points und einem neuen Dreijahresschlüssel für zwei. Die vorhandene Zeit bleibt erhalten. Läuft das Netz weiter mit fünf Access Points, liegen drei über dem neuen Limit.

Der Einkauf hat dann eine Verlängerung beschafft und zugleich eine kleinere Kapazität festgelegt. Das kann zu einem geplanten Rückbau passen. Bleiben die drei übrigen Geräte jedoch im Netz, muss der Betrieb auf die neue Grenze reagieren.

Für Co-Term beschreibt Meraki eine Schonfrist von 30 Tagen bei Überschreitung oder Ablauf. Bleibt der Lizenzzustand danach unbereinigt, folgt laut Dokumentation die Abschaltung der Organisation; die beschriebenen Folgen umfassen den Verlust von Verwaltung und Datenverkehr. Zu viele Geräte lassen sich durch Entfernen aus den Netzwerken oder zusätzliche Lizenzen korrigieren. Bei abgelaufener Deckung braucht der aktive Bestand neue Laufzeit.

Die allgemeinen Lizenzfragen führen Co-Term und Subscription als verfügbare Modelle, während das ältere PDL auf bestehende Nutzer beschränkt ist. Pro Organisation gilt ein Modell. Für die konkrete Voraussage fehlen hier Restlaufzeit, Lizenzlimits je Typ, deren Rechengewichte sowie Menge, Dauer und beabsichtigte Anwendung des neuen Schlüssels; diese Angaben würden den tatsächlichen Termin bestimmen.

Die Einkaufsfrage lässt sich trotzdem schon präzise formulieren: Welche zusätzliche Kapazität entsteht, und welches gemeinsame Datum steht danach im Kalender? Merakis eigenes Beispiel liefert den Grund, beide Antworten zusammen einzufordern.