Release Notes 24.12

Dieses Dokument beschreibt Ankündigungen und Abkündigungen im Leistungsumfang der ix.Cloud.

Ankündigungen

In diesem Abschnitt werden Änderungen an bestehenden sowie Einführungen neuer Funktionen und Services beschrieben, die im Umfang von diesem Release eingeführt wurden.

NewBackup

Der Backup Service wird mit der Einführung von "NewBackup" bezüglich dem erweiterten Service Umfang angepasst. Neben der Zugriffskontrolle und Datenverschlüsselung können die Backup Daten während der gesamten Aufbewahrungsdauer weder verändert noch gelöscht werden (Immutable Backup), zudem wurden die Backup Profile mit erweiterten Aufbewahrungsfristen optimiert.

Datenbank Security Audit

Der Database Service wird um den Service des Database Security Audit erweitert.

Wir bieten diese Service in 2 Teilen an, einem obligatorischen und optionalen Teil. Das obligatorische Database Security Audit wird mit jeder MSSQL und PostgreSQL Instance bereitgestellt. Das optionale Database Security Audit kann wir Change Request hinzugefügt werden.

Database Services

Patch Management

• Die Patches werden alle 4 Wochen in 3 Waves deployed
• Systeme, die nicht automatisch gepatcht werden können, werden monatlich manuell gepatcht. Der Patch-Vorgang und alle relevanten Informationen werden im Confluence dokumentiert.
• Beim Emergency Patching wird eine identifizierte kritische Schwachstelle umgehend gepatcht.

Logging

• Die Systeme werden durch unser Monitoring protokolliert, einschliesslich Event-Logs, Login's und Aufzeichnungen von Administratorenkonten.
• Die Logs werden 90 Tage online gespeichert, Statistiken werden 360 Tage vorgehalten.
• Eine Überwachung stellt sicher, dass die Log's fortlaufend aufgezeichnet werden. Im Fehlerfalle wird automatisch eine Ticket an den Betrieb gesendet.

Malware Schutz

• Der Malware Schutz wird mit dem Schutz über das Operating System sichergestellten.

Container Registry

Der Container Registry Service wurde um eine weiter Service Option "CVE allowlist" erweiter. Auf jedem Projekt/Repo kann ein Withlisting erstellt werden. Dieses gilt für alle Images in dieser Lokation (siehe Service Catalog Container Registry as a Service).

Namespace as a Service

Es gibt Applikationen welche mit den ResourceQuotas oder Networkpolicy vom Namespace nicht umgehen können. Diese können beim bestellen des Namespace deaktiviert werden.

AnyCloudK8s

AnyCloudK8s ist eine agnostische Container-Plattform und bietet volle Flexibilität und Unabhängigkeit vom zugrunde liegenden Cloud-Anbieter. Dadurch haben sie maximale Unterstützung für die Entwicklung und Verwaltung von cloud-nativer Anwendungen. Zusätzlich ist nun persistente Storage gemäss SLA Rhodium und SLA Silber automatisiert integriert(siehe AnyCloudK8s).

Abkündigungen

In diesem Abschnitt sind Funktionen und Service aufgeführt, die mit diesem Release aus dem Leistungsumfang entfernt werden.

info

Bei Abkündigungen kann mittels Change Request die Migration durch die Inventx unterstützt werden.

Container Services Agile Factory (Produkt Rancher)

Reminder Abkündigung Agile Factory Produkt Rancher Release-Notes 24.09

Change Log

Textliche Änderungen im Service Katalog werden pro Release im Change Log beschrieben.

Ziel ist es ein transparentes und nachvollziehbares Medium für inhaltliche Änderungen anzubieten.

Tabelle: Change Log

Neu	Alt	Wo
Die mit "◻" gekennzeichnete Positionen sind nicht im Basispreis enthalten, können aber optional dazu bestellt werden. Die Verrechnung erfolgt gemäss separater Preisliste.	Die mit "◻" gekennzeichnete Positionen sind nicht im Basispreis enthalten, können aber optional dazu bestellt werden. Die Verrechnung erfolgt gemäss separatem Preisblatt.	Zeichenlegende
<Anpassung Reaktionszeiten für P1 und P2 / P3 und P4 gelöscht>		on site Time Reaktionszeiten
<Tabelle gelöscht>		on site Time Wiederherstellungszeiten
<Anpassung Reaktionszeiten für P1 / P3 und P4 gelöscht>		on call Time Reaktionszeiten
<Tabelle gelöscht>		on call Time Reaktionszeiten
Beim Service Rack Collocation mietet der Kunde via "Generic Request" ein komplettes, dediziertes Rack oder den gewünschten Bedarf an Höheneinheiten in einem geteilten Rack in den Rechenzentren der Inventx. Die Systeme werden in diesem Fall durch den Kunden selbst verwaltet. Der Stromverbrauch wird individuell und nach effektivem Verbrauch abgerechnet. Der Strompreis wird jährlich gemäss Preisniveau der Stromlieferanten angepasst. Dieser Service steht nicht als Einzelservice zur Verfügung, sondern nur in Kombination mit weiteren Services dieses Servicekatalogs. Kunden profitieren durch diesen Service in den Fällen, in denen nebst dem Cloud-Service auch eine Lösung für das Hosting nicht cloud-fähiger Applikationen, Systeme oder Appliances nötig ist.	Beim Service Rack Collocation mietet der Kunde via "Generic Request" ein komplettes, dediziertes Rack oder den gewünschten Bedarf an Höheneinheiten in einem geteilten Rack in den Rechenzentren der Inventx. Die Systeme werden in diesem Fall durch den Kunden selbst verwaltet. Der Stromverbrauch wird individuell und nach effektivem Verbrauch abgerechnet. Der Strompreis wird jährlich gemäss Preisniveau der Stromlieferanten angepasst. Dieser Service steht nicht als Einzelservice zur Verfügung, sondern nur in Kombination mit weiteren Services dieses Servicekatalogs. Kunden profitieren durch diesen Service in den Fällen, in denen nebst dem Cloud-Service auch eine Lösung für das Hosting nicht cloud-fähiger Applikationen, Systemen oder Appliances nötig ist.	Rack Collocation
Wiederherstellung im Notfall RTO und RPO definieren im Rahmen eines Notfalls die maximale Dauer der Wiederherstellung (RTO) einer Anwendung, eines Systems und/ oder Prozesses und den maximalen Datenverlust (RPO).	Disaster Recovery Die Service Levels für Disaster Recovery definieren im Rahmen einer IT-Katastrophe die maximale Dauer der Wiederherstellung (RTO) und den maximalen Datenverlust (RPO) des Service.	Disaster Recovery
Die Konstellation bei einem Notfall kann sehr unterschiedlich sein und einen Einfluss auf diesen Service Level haben. Der Wert hängt dabei sehr stark von der Anzahl gleichzeitiger Wiederherstellungen ab, d.h. bei mehreren gleichzeitigen Wiederherstellungen kann der Wert pro Wiederherstellung geringer sein. Bei einer Wiederherstellung kann von einem Richtwert im Bereich 200-400 MB/s ausgegangen werden.	Das Service Level RTO ist die maximal zulässige Zeitspanne für die Wiederherstellung eines IT Services im Anschluss an eine Unterbrechung. Die Konstellation bei einem Desaster kann sehr unterschiedlich sein und einen Einfluss auf diesen Service Level haben. Der Wert hängt dabei sehr stark von der Anzahl gleichzeitiger Wiederherstellungen ab, d.h. bei mehreren gleichzeitigen Wiederherstellungen kann der Wert pro Wiederherstellung geringer sein. Bei einer Wiederherstellung kann von einem Richtwert im Bereich 200-400 MB/s ausgegangen werden.	RTO, Recovery Time Objective
Schadenereignisse hervorgerufen durch manipulierte, respektive korrupte Daten werden ausschliesslich durch die Backup relevanten Qualitätselemente im SLA abgedeckt. Dies bedeutet, dass falls korrupte Daten im Live-System vorhanden sind, diese lediglich aus einem Backup korrigiert werden können und der angegeben RPO somit nicht zur Anwendung kommt.	Der Service Level RPO definiert wie viele Daten/Transaktionen zwischen der letzten Sicherung und dem Systemausfall höchstens verloren gehen dürfen. Schadenereignisse hervorgerufen durch manipulierte, respektive korrupte Daten werden ausschliesslich durch die Backup relevanten Qualitätselemente im SLA abgedeckt. Dies bedeutet, dass falls korrupte Daten im Live-System vorhanden sind, diese lediglich aus einem Backup korrigiert werden können und der angegeben RPO somit nicht zur Anwendung kommt.	RPO, Recovery Point Objective
Inventx ist über die Schweizerische Vereinigung für Qualitäts- und Management-Systeme (SQS) ISO 27001 zertifiziert, und zwar über die ganze Firma mit allen Standorten/Prozessen inklusive den drei Datacentern. Zudem haben alle Controls, welche für die Schweiz angewendet werden können, Gültigkeit - die Inventx ist somit über die gesamte Firma mit allen Controls zertifiziert und lässt sich zusätzlich auch ISO 27017 und ISO 27018 durch SQS bestätigen.	Inventx ist über die Schweizerische Vereinigung für Qualitäts- und Management-Systeme (SQS) ISO 27'001 zertifiziert, und zwar über die ganze Firma mit allen Standorten/Prozessen inklusive den drei Datacentern. Zudem haben alle Controls, welche für die Schweiz angewendet werden können, Gültigkeit - die Inventx ist somit über die gesamte Firma mit allen Controls zertifiziert und lässt sich zusätzlich auch ISO 27'017 und ISO 27'018 durch SQS bestätigen.	Zertifizierungen
Die entsprechenden Ressourcen werden auf dem Zielsystem entfernt.	Die entsprechenden Ressourcen werden auf dem Zielssystem entfernt.	Löschvorgang einer Ressource
Der maximale Wert ist nicht limitiert, somit liegt es im Ermessen des Kunden, diesen zu definieren gemäss den vorhanden Ressourcen auf der Agile Factory. NOTE Die Memory Quota muss gedacht ausgewählt werden, da es die Applikationen zum Abstürzen bringen kann, wenn dieser zu knapp gewählt wird KubeConfig Jeder Container Namespace hat einen Service Account. Dieser Account kann mit unterschiedlicher Berechtigung bestellt werden. Entweder als Admin Service Account oder als Viewer. Zusätzlich zum Service Account, wird auch ein Token erstellt, welches nach der Ablaufzeit des definierten "Time to Live" abläuft. Die Definition, ob die Berechtigung Admin oder Viewer sein soll, kann nur bei der Erstellung des Container Namespace eingestellt werden. Das KubeConfig kann angezeigt und kopiert werden. Sollte die KubeConfig abgelaufen sein (erreichen der Time to Live) kann es erneuert werden. So ist sichergestellt, dass die Berechtigung auf den Namespace nicht immer die gleichen Credentials hat. NOTE Der Container Namespace kann nur auf dem Target Cluster gelöscht werden, wenn er mit Admin Rechte bestellt wurde.	Der maximaler Wert ist nicht limitiert, somit liegt es im ermessen des Kunden dieser zu definieren gemäss den vorhanden Ressourcen auf der Agile Factory. NOTE Die Memory Quota muss gedacht ausgewählt werden, da es die Applikationen zum abstürzen bringen kann wenn dieser zu knapp gewählt wird KubeConfig Jeder Container Namespace hat einen Service Account. Dieser Account kann mit unterschiedlicher Berrechtigung bestellt werden. Entweder als Admin Service Account oder als Viewer. Zusätzlich zum Service Account, wird auch ein Token erstellt, welches nach der Ablaufzeit des definierten "Time to Live" abläuft. Die Definition ob die Berechtigung Admin oder Viewer sein soll, kann nur bei der Erstellung des Container Namespace eingestellt werden. Das Kubeconfig kann angezeigt und kopiert werden. Sollte die Kubeconfig abgelaufen sein (erreichen der Time to Live) kann es erneuert werden. So ist sichergestellt, dass die Berechtigung auf den Namespace nicht immer die gleichen credentials hat. NOTE Der Contener Namespace kann nur auf dem Target Cluster gelöscht werden, wenn er mit Admin Rechte bestellt wurde	Container Namespace
Bestehende Services dürfen nur eingestellt, im Leistungsumfang reduziert oder anderweitig zum Nachteil des Kunden geändert werden, wenn Inventx den Kunden mindestens sechs (6) Monate zuvor schriftlich informiert.	Bestehende Services dürfen nur eingestellt, im Leistungsumfang reduziert oder anderweitig zum Nachteil des Kunden geändert werden, wenn Inventx den Kunden mindestens sechs (6) Monate zuvor schriftlich mittels Releasenotes informiert.	Änderungen des Leistungsumfangs
Die Preise kann Inventx jederzeit nach unten anpassen und mit jedem Release umsetzen. Preiserhöhungen werden dem Kunden mindestens vier (4) Monate zuvor schriftlich kommuniziert.	Die Preise kann Inventx jederzeit nach unten anpassen und mit jedem Release umsetzen. Preiserhöhungen werden dem Kunden mindestens vier (4) Monate zuvor schriftlich mittels Releasenotes kommuniziert.	Preisänderungen
Die aufgeführten, gesetzlichen Grundlagen, sowie die aufsichtsrechtlichen Vorgaben aus dem nächsten Kapitel, werden, sofern daraus auf vertraglicher Basis Pflichten und Verantwortlichkeiten an Inventx übertragen wurden, mindestens jährlich durch externe Experten überprüft. Weiterhin werden jährlich das sogenannte «Legal Register» zur Inventarisierung der relevanten gesetzlichen Grundlagen aktualisiert und mögliche Auswirkungen auf die zu erbringenden Leistungen beurteilt. Auch hier bilden die vertraglich übertragenen Pflichten zum Betrieb der relevanten Infrastrukturkomponenten und die daraus entstehenden Verantwortlichkeiten die Basis.	Die aufgeführten, gesetzlichen Grundlagen, sowie die aufsichtsrechtlichen Vorgaben aus dem nächsten Kapitel, werden, sofern daraus auf vertraglicher Basis Pflichten und Verantwortlichkeiten an Inventx übertragen wurden, mindestens jährlich durch externe Experten überprüft. Jährlich wird das sogenannte «Legal Register» zur Inventarisierung der relevanten gesetzlichen Grundlagen aktualisiert und mögliche Auswirkung auf die zu erbringenden Leistungen beurteilt. Auch hier bilden die vertraglich übertragenen Pflichten zum Betrieb der relevanten Infrastrukturkomponenten und die daraus entstehenden Verantwortlichkeiten die Basis.	Gesetzliche Grundlagen
Compute Services werden dazu verwendet, um Workload zu deployen, zu hosten und zu verwalten. In diesem Abschnitt werden die unterschiedlichen Services und deren Optionen in Bezug auf Compute-Services der ix.Cloud beschrieben.	Compute Services werden dazu verwendet, um Workload zu deployen, hosten und zu verwalten. In diesem Abschnitt werden die unterschiedlichen Services und deren Optionen in Bezug auf Compute-Services der ix.Cloud beschrieben.	Compute Services
Bei den Hardware-Profilen wird zwischen zwei Typen (Standard und Highclock) unterschieden. Der Hardware-Typ Standard hat Prozessoren mit einer niedrigen Taktfrequenz und ist für den Einsatz mit multithreading-fähigen Anwendungen geeignet. Beim Hardware-Typ Highclock hingegen, kommen Prozessoren mit erhöhter Taktfrequenz zum Einsatz, sie sind vor allem für nicht multithreading-fähigen Anwendungen geeignet.	Bei den Hardware-Profilen wird zwischen zwei Typen (Standard und Highclock) unterschieden. Der Hardware-Typ Standard hat Prozessoren mit einer niedrigen Taktfrequenz und ist für den Einsatz mit multithreading-fähigen Anwendungen geeignet. Beim Hardware-Typ Highclock hingegen, kommen Prozessoren mit erhöhter Taktfrequenz zum Einsatz und ist vor allem für nicht multithreading-fähigen Anwendungen geeignet.	Hardware Profile
Die System Management Services unterstützen Kunden, VM's und Anwendungen skalierbar auf Infrastruktur-Ebene resilient zu verwalten. Der Applikations Owner kann sich so einem Standard Tool-Set bedienen und sich ganz auf die Erfüllung seiner Kern-Elemente, der Verwaltung seiner Fachanwendungen, konzentrieren.	Die System Management Services unterstützen Kunden, VM's und Anwendungen skalierbar auf Infrastruktur-Ebene resilient zu verwalten. Der Applikations Owner kann sich so einem standard Tool-Set bedienen und sich ganz auf die Erfüllung seiner Kern-Elemente, der Verwaltung seiner Fachanwendungen, konzentrieren.	System Management Services
Die kontinuierliche Korrektur der Software im Hinblick auf Stabilität, Sicherheit und Aktualität.	Die Kontinuierliche Korrektur der Software im Hinblick auf Stabilität, Sicherheit und Aktualität.	Managed OS Patching
Mit «Container Services» bietet die ix.Cloud ein umfangreiches Tool-Set, um Micro-Services vollautomatisiert deployen und effizient verwalten zu können. Dabei fokussieren sie sich vollumfänglich auf ihre Anwendungen und Prozesse, während Inventx für sie die Infrastruktur betreibt und stetig weiterentwickelt.	Mit «Container Services» bietet die ix.Cloud ein umfangreiches Tool-Set, um Micro-Services vollautomatisiert deployen und effizient verwalten zu können. Dabei fokusieren sie sich vollumfänglich auf ihre Anwendungen und Prozesse, während Inventx für sie die Infrastruktur betreibt und stetig weiterentwickelt.	Container Services
Für persistente Daten wird die Agile Factory im Initial Setup mit persistentem Storage ausgestattet. Bei Bedarf kann der Kubernetes Cluster mit weiterem persistentem Storage ausgebaut werden. Typischerweise wird der persistente Storage vom Service File Storage bezogen. Optional kann auch der Service Object Storage als persistenter Storage genutzt werden.	Für persistente Daten wird die Agile Factory im Initial Setup mit persistem Storage ausgestatet. Bei Bedarf kann der Kubernetes Cluster mit weiterem persistentem Storage ausgebaut werden. Typischerweise wird der persistente Storage vom Service File Storage bezogen. Optional kann auch der Service Object Storage als persistenter Storage genutzt werden.	Container Services | Persistent Storage
Über die Authentication Authorization Infrastructure (AAI) und dem LDAP Operator kann ein individuelles RBAC-Konzept umgesetzt werden. Dazu werden vom Kunde definierten AD-Gruppen und Kubernetes Kluster Rollen miteinander verlinkt.	Über die Authentication Authorization Infrastructure (AAI) und dem LDAP Operator kann ein individuelles RBAC-Konzept umgesetzt werden. Dazu werdem vom Kunde definierten AD-Gruppen und Kubernetes Kluster Rollen miteinander verlinkt.	Container Services | Permission Management
Namespaces ist in Kubernetes zentral und ein Key-Element. Namespace ermöglichen es dem Entwickler, sein Projekt modular aufzubauen und bestimmte Aspekte in eine eigene Datei auszulagern. So können sie ihre Applikationen modernisieren und die Komplexität verringern, wodurch der Entwickler sich auf das wesentliche fokussieren kann.	Namespaces ist in Kubernets zentral und ein Key-Element. Namespace ermöglichen es dem Entwickler, sein Projekt modular aufzubauen und bestimmte Aspekte in eine eigene Datei auszulagern. So können sie ihre Applikationen modernisieren und die Komplexität verringern, wodurch der Entwickler sich auf das wesentliche fokussieren kann.	Container Services | Container Namespace
Es kann pro Subscription definiert werden, welche Target Destinationen verwendet werden können. So kann spezifisch definiert werden welche User auf welcher Agile Factory einen Container Namespace respektiv eine Applikation deployen darf.	Es kann pro Subscription definiert werden, welche Target Destinationen verwerndet werden können. So kann spezifisch definiert werden welche User auf welcher Agile Factory einen Container Namespace respektiv eine Applikation deployen darf.	Container Namespace | Target Destination