Anleitung zum Betrieb
Dieser Abschnitt enthält Anweisungen zur Ausführung von MS SQL auf IBM Cloud VPC vor und nach der ersten Bereitstellung der Microsoft SQL-Bereitstellungsmuster.
Weitere Informationen finden Sie unter Zuständigkeiten bei der Verwendung von Virtual Private Cloud verstehen.
Identity and Access Management
Identity and Access Management (IAM) ermöglicht die Steuerung von Ressourcen in Ihrem IBM Cloud -Konto. Ressourcen sind in Ressourcengruppen organisiert und erhalten über IAM-Zugriffsrichtlinien Zugriff auf Kontobenutzer und Service-IDs. Die Übernahme des Grundsatzes der Aufteilung von Aufgabenbereichen stellt sicher, dass Ihre IBM Cloud -Benutzer und -Service-IDs nur über den für die Ausführung ihrer Rollen erforderlichen Zugriff verfügen. Lesen Sie die folgenden Informationen, um sich zunächst mit IBM Cloud IAM vertraut zu machen und Ihr IBM Cloud -Konto für die Aufteilung von Aufgabenbereichen zu konfigurieren.
Activity Tracker
IBM Cloud Activity Tracker zeichnet Aktivitäten auf, die den Zustand eines Service in IBM Cloud über die UI/CLI/API ändern. Sie können den Service Activity Tracker verwenden, um abnormale Aktivitäten und kritische Aktionen zu untersuchen und die gesetzlichen Prüfvorschriften einzuhalten. Darüber hinaus können Sie über auftretende Aktionen benachrichtigt werden. Die erfassten Ereignisse entsprechen dem CADF-Standard (Cloud Auditing Data Federation). Informationen zu den in VPC überwachten Ereignissen und zur Einführung in Activity Trackerfinden Sie unter Activity Tracker .
Datenflussprotokolle
IBM Cloud Flow Logs for Virtual Private Cloud (VPC) ermöglichen die Erfassung, Speicherung und Darstellung von Informationen zum IP-Datenverkehr ( Internet Protocol ), der zu und von Netzschnittstellen in Ihrer VPC gesendet wird. Datenflussprotokolle können bei einer Reihe von Tasks hilfreich sein, z. B. bei der Fehlerbehebung, warum bestimmter Datenverkehr keine virtuelle Serverinstanz erreicht, um Sicherheitsgruppenregeln zu diagnostizieren und die Einhaltung von Konformitätsbestimmungen zu ermöglichen. Weitere Informationen finden Sie unter Informationen zu Datenflussprotokollen .
Ein Datenflussprotokoll ist eine Zusammenfassung des Netzverkehrs zwischen zwei virtuellen Netzschnittstellenkarten (vNICs) innerhalb eines Zeitfensters. Ein Datenflussprotokoll beschreibt den Datenverkehr, den Sicherheitsgruppen oder Netz-ACLs akzeptieren oder zurückweisen. Ein Nachrichtenflussprotokoll enthält Headerinformationen und Nutzdatenstatistiken für TCP-(Transmission Control Protocol) und UDP-Datenverkehr (User Datagram Protocol), nicht jedoch ICMP-Datenverkehr (Internet Control Message Protocol). Die Schlüsselkomponenten lauten wie folgt:
- Erfassung-Datenflussprotokollkollektoren werden für die Erfassung von Datenflussdaten konfiguriert und die Kollektoren können mit unterschiedlichen Geltungsbereichen konfiguriert werden:
- VPC-Erfasst Daten für alle Netzschnittstellen auf einer bestimmten VPC.
- Teilnetz-Erfasst Daten für alle Netzschnittstellen in einem bestimmten Teilnetz
- Instanz-Erfasst Daten für alle Netzschnittstellen auf einem bestimmten virtuellen Server
- Schnittstelle-Erfasst Daten für eine bestimmte Netzschnittstelle auf einem bestimmten virtuellen Server
- Speicher-Datenflussprotokolle werden in einem COS-Bucket ( IBM Cloud Object Storage ) gespeichert. Dieses Bucket wird während der Konfiguration des Datenflussprotokollkollektors konfiguriert.
- Präsentation- IBM Cloud SQL Query ist der IBMserverunabhängige SQL-Service für Daten in COS und wird verwendet, um Abfragen für die in COS gespeicherten Ablaufprotokolle zu erstellen. Weitere Informationen finden Sie unter Datenflussprotokollobjekte anzeigen und IBM Cloud SQL Query .
Überwachung
IBM Cloud Monitoring ist ein cloudnatives Überwachungssystem, das Sie als Teil Ihrer IBM Cloud -Architektur einschließen können, um Einblick in die Leistung und den Zustand Ihrer Server zu erhalten. Nachdem eine Instanz des Service IBM Cloud Monitoring bereitgestellt wurde, wird auf jedem zu überwachenden Host ein Überwachungsagent installiert. Über die Webbenutzerschnittstelle können Sie Ihre Ressourcen überwachen, Alerts konfigurieren und Ereignisse untersuchen.
Um ein Windows-System mit IBM Cloud Monitoringzu überwachen, wird der WMI-Exporter Prometheus zum Erfassen der Metriken auf dem System verwendet. Es gibt zwei Optionen für die Veröffentlichung der Metriken:
- Führen Sie einen Überwachungsagenten auf einem Linux-System aus und führen Sie über Fernzugriff das Scraping für den Windows-Endpunkt durch.
- Mit der 'remote-write'-Funktionalität von Prometheus können Sie Metriken vom Windows-System per Push-Operation übertragen, indem Sie Prometheus als Client-Collector unter Windows ausführen.
Informationen zur schrittweisen Installation und Konfiguration finden Sie unter Windows-Umgebung überwachen.
Protokollanalyse
Der Service IBM Log Analysis ermöglicht die Verwaltung von Ereignisprotokollen aus Ressourcen in IBM Cloud. IBM Log Analysis bietet Funktionen zum Filtern, Suchen, Definieren von Alerts sowie zum Entwerfen angepasster Ansichten zur Überwachung von Protokollen. Eine Übersicht über den Service finden Sie unter Übersicht . Log Analysis unterstützt die Windows-Protokollierung nicht nativ. Daher muss ein alternativer zentraler Protokollierungsservice verwendet werden.
Sicherung
Sicherung und Zurückschreibung auf SQL Server kann entweder als native Integration oder als Integration anderer Anbieter kategorisiert werden.
- Nativ-Weitere Informationen finden Sie unter Quickstart: Backup and restore a SQL Server database . Dort wird der Prozess zum Erstellen einer Datenbankgesamtsicherung und zum Wiederherstellen einer Sicherung mithilfe von SQL Server Management Studio (SSMS) beschrieben. Die Sicherung wird an der Sicherungsposition gespeichert, die während der Installation von SQL Server konfiguriert wurde, oder an einer benutzerdefinierten Position, z. B. einer Dateifreigabe. Sicherungen können mithilfe eines SQL Server Agent-Jobs geplant werden. Eine vollständige Beschreibung der Konzepte von SQL Server enthält der Abschnitt Backup-Übersicht (SQL Server).
- Integration von Drittanbietern-Es gibt eine Reihe von Integrationen von Drittanbietern, und hier beschreiben wir nur drei: IBM Spectrum Protect, Veeam und IBM Spectrum Protect Plus:
- Mit IBM Spectrum Protect -Data Protection for SQL können Sie Onlinesicherungen und -zurückschreibungen von Microsoft SQL Server -Datenbanken auf einem IBM Spectrum Protect Storage Manager-Server ausführen. Eine Beschreibung der Implementierung von IBM Spectrum Protect Storage Manager Server finden Sie unter IBM Spectrum Protect Cloud Blueprints. Informationen zur Installation von Data Protection for SQL finden Sie unter Download Information: Version 8.1.9 IBM Spectrum Protect for Databases.
- Veeam-Veeam Agent for Microsoft Windows ist eine Lösung für Datenschutz und Disaster-Recovery, die auf virtuellen Serverinstanzen von IBM Cloud VPC bereitgestellt werden kann. Weitere Informationen finden Sie unter Veeam Agent verwenden. Es ist auch möglich, Veeam Agent for Microsoft Windows mit Veeam Backup and Replication zu verwenden, wobei Veeam Backup and Replication eine zentrale Sicherungslösung für alle Ihre Veaam-Agenten bietet. Weitere Informationen finden Sie unter Veeam Backup and Replication-Software verwenden. Weitere Informationen zum Sichern von SQL Serverfinden Sie unter Microsoft SQL Server .
- IBM Spectrum Protect Plus - IBM Spectrum Protect Plus ist eine Datenschutzlösung für virtuelle Umgebungen, vSphere oder Hyper-V, und bietet Anwendungsdatenschutz für viele Anwendungen, einschließlich SQL Server, gehostet auf IBM Cloud VPC -Server. IBM Spectrum Protect Plus kann als eigenständige Lösung implementiert oder in Ihre IBM Spectrum Protect -Umgebung integriert werden, um Kopien für langfristige Speicherung und Governance auszulagern. IBM Spectrum Protect Plus kann automatisch in IBM Cloud in einer vorhandenen VMware -Umgebung installiert werden. Weitere Informationen finden Sie unter Spectrum Protect Plus Server . Spezielle Informationen zu IBM Spectrum Protect Plus und SQL Serverfinden Sie in SQL Server -Daten sichern und zurückschreiben.
IBM Cloud Security and Compliance Center
IBM Cloud Security and Compliance Center ermöglicht die Identifizierung von Sicherheitslücken, sodass Sie die Auswirkungen verringern und das Problem der Sicherheitslücke beheben können. Ein Red Hat Enterprise Linux-, CentOS-oder Ubuntu Virtual Server cx2-2x4 -Profil (2 vCPUs, 4 GB RAM und 4Gbps) muss in der VPC als Collector-Host implementiert werden. Ein Collector ist ein Softwaremodul, das als Docker-Image paketiert wird.
Ein Profil ist eine Sammlung zusammengehöriger Ziele oder Sicherheitsprüfungen, die verwendet werden, um Ihre Ressourcen anhand interner und externer Bestimmungen zu validieren. Siehe Sicherheits-und Konformitätsstatus mit VPC überwachen .
Ein Bereich wird verwendet, um den Fokus eines Scans auf eine bestimmte Umgebung, Region oder Ressource einzugrenzen. Anschließend wird ein Scan geplant, um Ressourcen zu erkennen, ihre Konfiguration zu bewerten und ihre Konformität anhand eines vordefinierten Profils zu validieren. Siehe Erste Schritte mit Security and Compliance Center .
Data encryption
Primäre Bootdatenträger und sekundäre Datenträger für Daten werden automatisch mithilfe der von IBMverwalteten Verschlüsselung verschlüsselt. Sie können jedoch auch Ihre eigene Verschlüsselung mithilfe der vom Kunden verwalteten Verschlüsselung verwalten. Unterstützte Schlüsselmanagementservices sind Key Protect und Hyper Protect Crypto Services (HPCS). Weitere Informationen finden Sie unter Informationen zur Datenverschlüsselung für VPC.
Sicherheitsgruppen
IBM Cloud Security Groups for VPC ermöglichen die Anwendung von Regeln, die die Filterung für jede Netzschnittstelle einer virtuellen Serverinstanz auf der Basis ihrer IP-Adresse ermöglichen.
- Standardmäßig weist eine Sicherheitsgruppe den gesamten Datenverkehr zurück.
- Beim Hinzufügen von Regeln wird der zulässige Datenverkehr definiert.
- Regeln sind statusabhängig, daher wird der umgekehrte Datenverkehr als Reaktion auf den zulässigen Datenverkehr automatisch zugelassen.
- Der Geltungsbereich einer Sicherheitsgruppe ist auf eine einzelne VPC-Instanz begrenzt.
- Wenn Sie mehrere virtuelle Server in einer Sicherheitsgruppe haben, muss der Datenverkehr zwischen Servern weiterhin zugelassen werden.
Weitere Informationen finden Sie unter Informationen zu Sicherheitsgruppen.
Zugriffssteuerungslisten (ACLs)
Zugriffssteuerungslisten (Access Control Lists, ACL) steuern den gesamten eingehenden und ausgehenden Datenverkehr zu und von VPC-Teilnetzen und nicht eine Sicherheitsgruppe, die den Datenverkehr zu und von virtuellen Serverinstanzen steuert.
- Eine ACL ist statusunabhängig, d. h., die Regeln für eingehende und abgehende Anforderungen müssen separat und explizit angegeben werden.
- Jede ACL besteht aus Regeln, die auf einer Quellen-IP, einem Quellenport, einer Ziel-IP, einem Zielport und einem Protokoll basieren.
- Einem Teilnetz kann jeweils nur eine ACL zugeordnet sein, aber eine ACL kann mehreren Teilnetzen zugeordnet werden.
- Regeln werden der Reihe nach verarbeitet
- Jede VPC verfügt über eine Standard-ACL, die den gesamten ein- und ausgehenden Datenverkehr zulässt.
Microsoft Windows Server schützen
Center for Internet Security-Benchmarks (CIS) sind Konfigurationsreferenzversionen und Best Practices für die sichere Konfiguration eines Systems und verweisen auf mindestens eine CIS -Steuerung. CIS -Steuerelemente entsprechen vielen etablierten Standards und Regulierungsframeworks, einschließlich NIST Cybersecurity Framework (CSF) und NIST SP 800-53, der ISO 27000-Serie von Standards, PCI DSS, HIPAA und anderen. Informationen zur Abschottung des Windows-Betriebssystems finden Sie unter Microsoft Windows Server sichern und Informationen zur Abschottung von MS SQL 2019 unter Microsoft SQL Server .
Windows-Server-Patching
Es gibt keine Microsoft-Aktualisierungsserver im IBM Cloud VPC -Netz. Daher ist der Zugriff auf die Microsoft-Repositorys über das Internet erforderlich. Dies kann wie folgt erreicht werden:
- Weitere Informationen zum Zuordnen einer variablen IP-Adresse zum virtuellen Server finden Sie unter Variable IP-Adresse für externe Konnektivität einer virtuellen Serverinstanz verwenden .
- Weitere Informationen zum Angriff eines öffentlichen Gateways auf ein Teilnetz finden Sie unter Öffentliches Gateway für externe Konnektivität eines Teilnetzes verwenden .
- Implementieren Sie WSUS (Windows Server Update Services) auf einer virtuellen Serverinstanz im Bastionsteilnetz und verwenden Sie ein öffentliches Gateway für externen Zugriff auf Microsoft. Informationen zur Implementierung von WSUS und zur Konfiguration von Servern für die Verwendung des WSUS-Servers finden Sie unter Deploy Windows Server Update Services .
Sie müssen Sicherheitsgruppen und/oder Zugriffssteuerungslisten aktualisieren, um diesen Aktualisierungsdatenverkehr zuzulassen.
Patching für SQL Server
Microsoft gibt alle zwei Monate Cumulative Packs (CU) für SQL Server frei. Jede Leistungseinheit enthält das vorherige kumulative Paket. Für SQL Server 2019 können Sie auf die Leistungseinheiten unter Neueste Aktualisierungen für Microsoft SQL Serverzugreifen. Weitere Informationen finden Sie unter SQL Server 2019 Buildversionen.
Im Folgenden finden Sie eine kurze Zusammenfassung des Patchinstallationsprozesses in einer Verfügbarkeitsgruppe "Immer verfügbar":
- Vorbereitung:
- Ermitteln Sie den aktuellen Patch-Level.
- Definieren Sie den Ziel-Patch-Level, d. h. N oder N-1.
- Lesen Sie die Releaseinformationen zum Patch.
- Ein bewährtes Verfahren besteht darin, den Patch in einer Testumgebung vor dem Patching einer Produktionsumgebung zu testen.
- Stellen Sie sicher, dass Sie über die neuesten Sicherungen für die Systemdatenbanken und Benutzerdatenbanken im primären Replikat verfügen. Idealerweise verfügen Sie über Gesamtsicherungen. Für sehr große Datenbanken muss jedoch entweder eine Differenzsicherung oder die Transaktionsprotokollsicherung verfügbar sein
- Halten Sie auf den sekundären Replikaten die neueste Systemdatenbanksicherung bereit.
- Überprüfen Sie den Zustand der Verfügbarkeitsgruppe über das Verfügbarkeitsdashboard in SQL Server Management Studio. Die Verfügbarkeitsgruppendatenbanken müssen den Status "Synchronisiert" für das synchrone Commit und den Status "Synchronisiert" für den asynchronen Commit-Modus haben.
- Patching:
- Wenden Sie das Patch auf das sekundäre Replikat im primären MZR an, d. h. auf den SQL-Server in AZ2, falls zutreffend:
- Ändern Sie mithilfe von SSMS den Failover-Modus von Automatisch in Manuell, um sicherzustellen, dass während der Installation der Patches keine automatische Funktionsübernahme erfolgt.
- Setzen Sie mit SSMS das Versetzen von Daten für die sekundären Replikatdatenbanken aus, sodass das primäre Replikat keinen Transaktionsblock an das spezifische sekundäre Replikat sendet.
- Wenden Sie die Leistungseinheit über RDP auf den Server an, auf dem sich das sekundäre Replikat befindet.
- Starten Sie den Server erneut.
- Sobald das sekundäre Replikat online ist, stellen Sie über SSMS eine Verbindung zu ihm her und führen die folgende Überprüfung durch:
- Überprüfen Sie, ob SQL Services online sind.
- SQL Server -Versionsvalidierung.
- Überprüfen Sie die SQL Server -Fehlerprotokolle auf Fehler und Warnungen.
- Es wird auch empfohlen, ein Datenbankkonsistenzprüfprogramm (DBCC CHECKDB) auszuführen, nachdem die Patches angewendet wurden.
- Nehmen Sie mithilfe von SSMS das Versetzen von Daten in die sekundäre Replikatdatenbank wieder auf und warten Sie, bis das Verfügbarkeitsgruppendashboard in einwandfreiem Zustand angezeigt wird.
- Wenden Sie das Patch auf das sekundäre Replikat im Recovery-MZR an, falls zutreffend:
- Setzen Sie mit SSMS das Versetzen von Daten für die sekundären Replikatdatenbanken aus, sodass das primäre Replikat keinen Transaktionsblock an das spezifische sekundäre Replikat sendet.
- Wenden Sie die Leistungseinheit über RDP auf den Server an, auf dem sich das sekundäre Replikat befindet.
- Starten Sie den Server erneut.
- Sobald das sekundäre Replikat online ist, stellen Sie über SSMS eine Verbindung zu ihm her und führen die folgende Überprüfung durch:
- Überprüfen Sie, ob SQL Services online sind.
- SQL Server -Versionsvalidierung.
- Überprüfen Sie die SQL Server -Fehlerprotokolle auf Fehler und Warnungen.
- Es wird auch empfohlen, ein Datenbankkonsistenzprüfprogramm (DBCC CHECKDB) auszuführen, nachdem die Patches angewendet wurden.
- Nehmen Sie mithilfe von SSMS das Versetzen von Daten in die sekundäre Replikatdatenbank wieder auf und warten Sie, bis das Verfügbarkeitsgruppendashboard in einwandfreiem Zustand angezeigt wird.
- Wenden Sie das Patch auf das primäre Replikat an:
- Führen Sie mit SSMS einen manuellen Failover vom primären Replikat auf das sekundäre Replikat im primären MZR durch. Nach dem Failover ändert das primäre Replikat seinen Status in ein sekundäres Replikat.
- Setzen Sie mit SSMS das Versetzen von Daten für die sekundären Replikatdatenbanken aus, sodass das primäre Replikat keinen Transaktionsblock an das spezifische sekundäre Replikat sendet.
- Wenden Sie die Leistungseinheit über RDP auf den Server an, auf dem sich das sekundäre Replikat befindet.
- Starten Sie den Server erneut.
- Sobald das sekundäre Replikat online ist, stellen Sie über SSMS eine Verbindung zu ihm her und führen die folgende Überprüfung durch:
- Überprüfen Sie, ob SQL Services online sind.
- SQL Server -Versionsvalidierung.
- Überprüfen Sie die SQL Server -Fehlerprotokolle auf Fehler und Warnungen.
- Es wird auch empfohlen, ein Datenbankkonsistenzprüfprogramm (DBCC CHECKDB) auszuführen, nachdem die Patches angewendet wurden.
- Führen Sie mithilfe von SSMS ein Failback der Verfügbarkeit durch. Nach dem Failover ist das primäre Replikat der Verfügbarkeitsgruppe der primäre Knoten.
- Ändern Sie den Failover-Modus für die primären und sekundären Replikate, die mit dem synchronen Datenfestschreibungsmodus konfiguriert sind, in "Automatisch".
- Wenden Sie das Patch auf das sekundäre Replikat im primären MZR an, d. h. auf den SQL-Server in AZ2, falls zutreffend:
- Nach der Patchinstallation:
- Führen Sie mithilfe von SSMS ein Failover und Failback der Verfügbarkeitsgruppe durch und überprüfen Sie, ob das SSMS-Verfügbarkeitsdashboard in einwandfreiem Zustand ist.
- Überprüfen Sie die Fehlerprotokolle für alle Replikate.
- Überprüfen Sie den Anwendungszugriff.