Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Automatisieren Sie anwendungskonsistente Snapshots mit Data Lifecycle Manager
Sie können anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager automatisieren, indem Sie in Ihren Snapshot-Lebenszyklusrichtlinien Vor- und Nach-Skripts aktivieren, die auf Instances abzielen.
Amazon Data Lifecycle Manager ist in AWS Systems Manager (Systems Manager) integriert, um anwendungskonsistente Snapshots zu unterstützen. Amazon Data Lifecycle Manager verwendet Systems-Manager-Befehlsdokumente (SSM-Befehlsdokumente), die Vor- und Nach-Skripte enthalten, um die Aktionen zu automatisieren, die für die Erstellung anwendungskonsistenter Snapshots erforderlich sind. Bevor Amazon Data Lifecycle Manager die Snapshot-Erstellung initiiert, führt es die Befehle im Vor-Skript aus, um die I/O einzufrieren und zu leeren. Nachdem Amazon Data Lifecycle Manager die Snapshot-Erstellung initiiert hat, führt es die Befehle im Nach-Skript aus, um die I/O aufzutauen.
Amazon Data Lifecycle Manager ermöglicht die Automatisierung anwendungskonsistenter Snapshots der folgenden Elemente:
-
Windows-Anwendungen unter Verwendung von Volume Shadow Copy Service (VSS)
-
SAP HANA verwendet ein AWS verwaltetes SSDM-Dokument. Weitere Informationen finden Sie unter Amazon-EBS-Snapshots für SAP HANA.
-
Selbstverwaltete Datenbanken wie MySQL, PostgreSQL oder InterSystems IRIS mit SSM-Dokumentvorlagen
Anforderungen an die Verwendung von Vor- und Nach-Skripten
In der folgenden Tabelle werden die Anforderungen an die Verwendung von Vor- und Nach-Skripten mit Amazon Data Lifecycle Manager beschrieben.
|
Anwendungskonsistente Snapshots |
|
Anforderung |
VSS-Backup |
Benutzerdefiniertes SSM-Dokument |
Andere Anwendungsfälle |
Der SSM-Agent ist auf den Ziel-Instances installiert und wird dort ausgeführt |
✓ |
✓ |
✓ |
Die VSS-Systemanforderungen auf den Zielinstanzen wurden erfüllt |
✓ |
|
|
VSS-fähiges Instanzprofil, das den Zielinstanzen zugeordnet ist |
✓ |
|
|
Auf Zielinstanzen installierte VSS-Komponenten |
✓ |
|
|
Bereiten Sie das SSM-Dokument mit Pre- und Post-Skriptbefehlen vor |
|
✓ |
✓ |
Vorbereiten der Amazon Data Lifecycle Manager Manager-IAM-Rolle, Ausführen von Vor- und Nachskripten |
✓ |
✓ |
✓ |
Erstellen Sie eine Snapshot-Richtlinie, die auf Instances abzielt und für Vor- und Nachskripte konfiguriert ist |
✓ |
✓ |
✓ |
Erste Schritte mit anwendungskonsistenten Snapshots
In diesem Abschnitt werden die Schritte erläutert, die Sie ausführen müssen, um anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager zu automatisieren.
Sie müssen die Ziel-Instances für anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager vorbereiten. Führen Sie je nach Anwendungsfall einen der folgenden Schritte durch.
- Prepare for VSS Backups
-
- Prepare for SAP HANA backups
-
Zur Vorbereitung Ihrer Ziel-Instances für SAP–HANA-Backups
-
Bereiten Sie die SAP-HANA-Umgebung auf Ihre Ziel-Instances vor.
-
Richten Sie Ihre Instance mit SAP HANA ein. Wenn Sie noch nicht über eine bestehende SAP-HANA-Umgebung verfügen, finden Sie unter Einrichtung einer SAP-HANA-Umgebung auf AWS weitere Informationen.
-
Melden Sie sich als geeigneter Administratorbenutzer bei der SystemDB an.
-
Erstellen Sie einen Datenbank-Backup-Benutzer, der mit Amazon Data Lifecycle Manager verwendet werden soll.
CREATE USER username
PASSWORD password
NO FORCE_FIRST_PASSWORD_CHANGE;
Mit dem folgenden Befehl wird beispielsweise ein Benutzer mit dem Namen dlm_user
und dem Passwort password
erstellt.
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
-
Weisen Sie die BACKUP OPERATOR
-Rolle dem Datenbank-Backup-Benutzer zu, den Sie im vorherigen Schritt erstellt haben.
GRANT BACKUP OPERATOR TO username
Mit dem folgenden Befehl wird die Rolle beispielsweise einem Benutzer mit dem Namen dlm_user
zugewiesen.
GRANT BACKUP OPERATOR TO dlm_user
-
Melden Sie sich als Administrator beim Betriebssystem an, beispielsweise sid
adm
.
-
Erstellen Sie einen hdbuserstore
-Eintrag zum Speichern von Verbindungsinformationen, sodass das SAP-HANA-SSM-Dokument eine Verbindung zu SAP HANA herstellen kann, ohne dass Benutzer die Informationen eingeben müssen.
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number
13 username
password
Zum Beispiel:
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
-
Testen Sie die Verbindung.
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
-
Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
Weitere Informationen finden Sie unter Manuelles Installieren des SSM-Agenten auf EC2 Instances für Linux.
-
Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter Prüfen des Status des SSM-Agents und Starten des Agenten.
-
Richten Sie Systems Manager für EC2 Amazon-Instances ein. Weitere Informationen finden Sie im AWS Systems Manager Benutzerhandbuch unter Systems Manager für EC2 Amazon-Instances einrichten.
- Prepare for custom SSM documents
-
Vorbereitung benutzerdefinierter SSM-Dokumente für Ihre Ziel-Instances
-
Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
-
Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter Prüfen des Status des SSM-Agents und Starten des Agenten.
-
Richten Sie Systems Manager für EC2 Amazon-Instances ein. Weitere Informationen finden Sie im AWS Systems Manager Benutzerhandbuch unter Systems Manager für EC2 Amazon-Instances einrichten.
Dieser Schritt ist nur für benutzerdefinierte SSM-Dokumente erforderlich. Für VSS-Backup oder SAP HANA ist er nicht erforderlich. Für VSS-Backups und SAP HANA verwendet Amazon Data Lifecycle Manager das AWS verwaltete SSM-Dokument.
Wenn Sie anwendungskonsistente Snapshots für eine selbstverwaltete Datenbank wie MySQL, PostgreSQL oder InterSystems IRIS automatisieren, müssen Sie ein SSM-Befehlsdokument erstellen, das ein Pre-Skript zum Einfrieren und Leeren von I/O enthält, bevor die Snapshot-Erstellung initiiert wird, und ein Post-Skript zum Auftauen von I/O nach Initiierung der Snapshot-Erstellung.
Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank Standardkonfigurationen verwendet, können Sie mithilfe des folgenden SSM-Beispieldokuments ein SSM-Befehlsdokument erstellen. Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank eine nicht standardmäßige Konfiguration verwendet, können Sie den folgenden Beispielinhalt als Ausgangspunkt für Ihr SSM-Befehlsdokument verwenden und es dann an Ihre Anforderungen anpassen. Wenn Sie ein SSM-Dokument von Grund auf neu erstellen möchten, können Sie alternativ die leere SSM-Dokumentvorlage unten verwenden und Ihre Vor- und Nach-Befehle in den entsprechenden Dokumentabschnitten hinzufügen.
-
Sie müssen sicherstellen, dass das SSM-Dokument die richtigen und erforderlichen Aktionen für Ihre Datenbankkonfiguration ausführt.
-
Snapshots sind nur dann garantiert anwendungskonsistent, wenn die Vor- und Nach-Skripte in Ihrem SSM-Dokument die I/O erfolgreich einfrieren, leeren und wieder auftauen können.
-
Das SSM-Dokument muss die erforderlichen Felder für allowedValues
enthalten, einschließlich pre-script
, post-script
und dry-run
. Amazon Data Lifecycle Manager führt Befehle auf Ihrer Instance basierend auf den Inhalten dieser Abschnitte aus. Wenn Ihr SSM-Dokument diese Abschnitte nicht enthält, behandelt Amazon Data Lifecycle Manager dies als fehlgeschlagene Ausführung.
- MySQL sample document content
-
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run MySQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###=================================================================###
### Global variables
###=================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen.
unfreeze_fs
thaw_db
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
sudo mysql -e 'UNLOCK TABLES;'
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
thaw_db
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Flush and Lock command."
sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
# If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed."
exit 201
fi
sync
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command."
fi
}
thaw_db() {
# Run the unlock command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Unlock"
sudo mysql -e 'UNLOCK TABLES;'
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
export -f thaw_db
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
- PostgreSQL sample document content
-
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run PostgreSQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen
unfreeze_fs
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when PostgreSQL DB service is up and running
sudo systemctl is-active --quiet postgresql
if [ $? -eq 0 ]; then
echo "INFO: Execute Postgres CHECKPOINT"
# PostgreSQL command to flush the transactions in memory to disk
sudo -u postgres psql -c 'CHECKPOINT;'
# If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: Postgres CHECKPOINT command failed."
exit 201
fi
sync
else
echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
- InterSystems IRIS sample document content
-
###===============================================================================###
# MIT License
#
# Copyright (c) 2024 InterSystems
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS.
parameters:
executionId:
type: String
default: None
description: Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
type: String
# Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes.
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
#The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run InterSystems IRIS Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Global variables
###===============================================================================###
DOCKER_NAME=iris
LOGDIR=./
EXIT_CODE=0
OPERATION={{ command }}
START=$(date +%s)
# Check if Docker is installed
# By default if Docker is present, script assumes that InterSystems IRIS is running in Docker
# Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present).
# Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration.
if command -v docker &> /dev/null
then
DOCKER_EXEC="docker exec $DOCKER_NAME"
else
DOCKER_EXEC="sudo -i -u irissys"
fi
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to freeze $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status before starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: ERROR: $INST IS already FROZEN"
EXIT_CODE=204
else
echo "`date`: $INST is not frozen"
# Freeze
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)"
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN"
;;
3) echo "`date`: $INST FREEZE FAILED"
EXIT_CODE=201
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=201
;;
esac
echo "`date`: Completed freeze of $INST"
fi
done
echo "`date`: Pre freeze script finished"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to thaw $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status befor starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: $INST is in frozen state"
# Thaw
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")"
status=$?
case $status in
5) echo "`date`: $INST IS THAWED"
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")"
;;
3) echo "`date`: $INST THAW FAILED"
EXIT_CODE=202
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=202
;;
esac
echo "`date`: Completed thaw of $INST"
else
echo "`date`: ERROR: $INST IS already THAWED"
EXIT_CODE=205
fi
done
echo "`date`: Post thaw script finished"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
# return failure
EXIT_CODE=1
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
exit $EXIT_CODE
Weitere Informationen finden Sie im Repository. GitHub
- Empty document template
-
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
Sobald Sie über den Inhalt Ihres SSM-Dokuments verfügen, verwenden Sie eines der folgenden Verfahren, um das benutzerdefinierte SSM-Dokument zu erstellen.
- Console
-
Erstellen eines SSM-Befehlsdokuments
-
Öffnen Sie die AWS Systems Manager Konsole unter https://console.aws.amazon.com//systems-manager/.
-
Wählen Sie im Navigationsbereich Dokumente und dann Dokument erstellen, Befehl oder Sitzung aus.
-
Geben Sie unter Name einen aussagekräftigen Namen für das Dokument ein.
-
Wählen Sie als Zieltyp die Option/ausAWS::EC2::Instance.
-
Wählen Sie als Dokumenttyp Befehl.
-
Wählen Sie im Feld Inhalt die Option YAML aus und fügen Sie dann den Inhalt des Dokuments ein.
-
Fügen Sie im Abschnitt Dokument-Tags ein Tag mit einem Tag-Schlüssel von DLMScriptsAccess
und einem Tag-Wert von true
hinzu.
Das DLMScriptsAccess:true
Tag ist für die in Schritt 3: Vorbereiten der Amazon Data Lifecycle AWS Manager-IAM-Rolle verwendete AWSDataLifecycleManagerSSMFullAccess Manager-Richtlinie erforderlich. Die Richtlinie verwendet den aws:ResourceTag
-Bedingungsschlüssel, um den Zugriff auf SSM-Dokumente mit diesem Tag einzuschränken.
-
Wählen Sie Create document (Dokument erstellen) aus.
- AWS CLI
-
Erstellen eines SSM-Befehlsdokuments
Verwenden Sie den Befehl create-document. Geben Sie für --name
einen beschreibenden Namen für das Dokument ein. Legen Sie für --document-type
die Option Command
fest. Geben Sie für --content
den Pfad zur .yaml-Datei mit dem SSM-Dokumentinhalt an. Legen Sie für --tags
die Option "Key=DLMScriptsAccess,Value=true"
fest.
$
aws ssm create-document \
--content file://path/to/file/documentContent.yaml
\
--name "document_name
" \
--document-type "Command" \
--document-format YAML \
--tags "Key=DLMScriptsAccess,Value=true"
Dieser Schritt ist erforderlich, wenn:
-
Sie eine Snapshot-Richtlinie mit aktiviertem Vor-/Nach-Skript erstellen oder aktualisieren, die eine benutzerdefinierte IAM-Rolle verwendet.
-
Sie die Befehlszeile verwenden, um eine Snapshot-Richtlinie mit aktiviertem Vor-/Nach-Skript zu erstellen oder zu aktualisieren, die die Standardeinstellung verwendet.
Wenn Sie die Konsole verwenden, um eine Snapshot-Richtlinie mit aktiviertem Pre-/Post-Skript zu erstellen oder zu aktualisieren, die die Standardrolle für die Verwaltung von Snapshots () AWSDataLifecycleManagerDefaultRoleverwendet, überspringen Sie diesen Schritt. In diesem Fall hängen wir die AWSDataLifecycleManagerSSMFullZugriffsrichtlinie automatisch an diese Rolle an.
Sie müssen sicherstellen, dass die für die Richtlinie verwendete IAM-Rolle Amazon Data Lifecycle Manager die Erlaubnis erteilt, die SSM-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf Instances, auf die die Richtlinie abzielt, erforderlich sind.
Amazon Data Lifecycle Manager bietet eine verwaltete Richtlinie (AWSDataLifecycleManagerSSMFullAccess), die die erforderlichen Berechtigungen beinhaltet. Sie können diese Richtlinie an Ihre IAM-Rolle für die Verwaltung von Snapshots anhängen, um sicherzustellen, dass sie die entsprechenden Berechtigungen beinhaltet.
Die verwaltete AWSData LifecycleManager SSMFull Access-Richtlinie verwendet den aws:ResourceTag
Bedingungsschlüssel, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Pre- und Post-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag DLMScriptsAccess:true
enthalten.
Alternativ können Sie manuell eine benutzerdefinierte Richtlinie erstellen oder die erforderlichen Berechtigungen direkt der von Ihnen verwendeten IAM-Rolle zuweisen. Sie können dieselben Berechtigungen verwenden, die in der verwalteten AWSData LifecycleManager SSMFull Access-Richtlinie definiert sind, der aws:ResourceTag
Bedingungsschlüssel ist jedoch optional. Wenn Sie sich dafür entscheiden, diesen Bedingungsschlüssel nicht zu verwenden, müssen Sie Ihre SSM-Dokumente nicht mit DLMScriptsAccess:true
markieren.
Verwenden Sie eine der folgenden Methoden, um die AWSDataLifecycleManagerSSMFullAccess-Richtlinie zu Ihrer IAM-Rolle hinzuzufügen.
- Console
-
So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an
-
Öffnen Sie unter https://console.aws.amazon.com/iam/ die IAM-Konsole.
-
Wählen Sie im Navigationspanel Rollen aus.
-
Suchen Sie nach Ihrer benutzerdefinierten Rolle zur Verwaltung von Snapshots und wählen Sie sie aus.
-
Wählen Sie auf der Registerkarte Berechtigungen Berechtigungen hinzufügen und dann Richtlinien anfügen aus.
-
Suchen Sie nach der verwalteten AWSDataLifecycleManagerSSMFullAccess-Richtlinie, wählen Sie sie aus und klicken Sie dann auf Berechtigungen hinzufügen.
- AWS CLI
-
So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an
Verwenden Sie den Befehl attach-role-policy. Geben Sie für ---role-name
den Namen Ihrer benutzerdefinierten Rolle an. Legen Sie für --policy-arn
die Option arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess
fest.
$
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
Um anwendungskonsistente Snapshots zu automatisieren, müssen Sie eine Snapshot-Lebenszyklusrichtlinie für Instances erstellen und Vor- und Nach-Skripte für diese Richtlinie konfigurieren.
- Console
-
So erstellen Sie die Snapshot-Lebenszyklusrichtlinie
Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/.
-
Wählen Sie im Navigationsbereich Elastic Block Store und Lifecycle Manager aus. Wählen Sie dann Create lifecycle policy (Lebenszyklusrichtlinie erstellen) aus.
-
Wählen Sie auf dem Bildschirm Richtlinientyp auswählen die Option EBS-Snapshot-Richtlinie und dann Weiter aus.
-
Gehen Sie im Abschnitt Zielressourcen wie folgt vor:
-
Wählen Sie für Ziel-Ressourcentypen die Option Instance
.
-
Geben Sie für Zielressourcen-Tags die Ressourcen-Tags an, die die zu sichernden Instances identifizieren. Nur Ressourcen mit den angegebenen Tags werden gesichert.
-
Wählen Sie für die IAM-Rolle entweder AWSDataLifecycleManagerDefaultRole(die Standardrolle für die Verwaltung von Snapshots) oder eine benutzerdefinierte Rolle, die Sie für Pre- und Post-Skripte erstellt und vorbereitet haben.
-
Konfigurieren Sie die Zeitpläne und zusätzlichen Optionen nach Bedarf. Wir empfehlen Ihnen, die Snapshot-Erstellung für Zeiträume einzuplanen, die Ihrem Workload entsprechen, z. B. während Wartungsfenstern.
Für SAP HANA empfehlen wir, die schnelle Snapshot-Wiederherstellung zu aktivieren.
Wenn Sie einen Zeitplan für VSS-Backups aktivieren, können Sie die Optionen Ausschließen bestimmter Daten-Volumes oder Tags aus der Quelle kopieren nicht aktivieren.
-
Wählen Sie im Abschnitt Vor- und Nach-Skripte die Option Vor- und Nach-Skripte aktivieren aus und gehen Sie dann je nach Workload wie folgt vor:
-
Um anwendungskonsistente Snapshots Ihrer Windows-Anwendungen zu erstellen, wählen Sie VSS-Backup.
-
Um anwendungskonsistente Snapshots Ihrer SAP-HANA-Workloads zu erstellen, wählen Sie SAP HANA.
-
Um mithilfe eines benutzerdefinierten SSM-Dokuments anwendungskonsistente Snapshots aller anderen Datenbanken und Workloads zu erstellen, einschließlich Ihrer selbstverwalteten MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, wählen Sie Benutzerdefiniertes SSM-Dokument aus.
-
Wählen Sie für Option automatisieren Vor- und Nach-Skripte aus.
-
Wählen Sie unter SSM-Dokument das SSM-Dokument aus, das Sie vorbereitet haben.
-
Konfigurieren Sie je nach der ausgewählten Option die folgenden zusätzlichen Optionen:
-
Timeout für das Skript – (nur benutzerdefiniertes SSM-Dokument) Der Timeout-Zeitraum, nach dem Amazon Data Lifecycle Manager die versuchte Skriptausführung als fehlgeschlagen behandelt, wenn sie nicht abgeschlossen wurde. Wenn ein Skript nicht innerhalb des Timeout-Zeitraums abgeschlossen wird, schlägt der Versuch von Amazon Data Lifecycle Manager fehl. Der Timeout-Zeitraum gilt für die Vor- und Nach-Skripte einzeln. Der Minimal- und Standardwert für den Timeout beträgt 10 Sekunden. Die maximale Timeout-Zeit beträgt 120 Sekunden.
-
Fehlgeschlagene Skripte erneut versuchen – Wählen Sie diese Option, um Skripte zu wiederholen, die nicht innerhalb ihres Timeouts abgeschlossen werden. Wenn das Vor-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager den gesamten Snapshot-Erstellungsprozess, einschließlich der Ausführung der Vor- und Nach-Skripte. Wenn das Nach-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager nur das Nach-Skript. In diesem Fall ist das Vor-Skript abgeschlossen und der Snapshot wurde möglicherweise erstellt.
-
Standardmäßig absturzkonsistente Snapshots – Wählen Sie diese Option, um standardmäßig absturzkonsistente Snapshots zu verwenden, falls das Vor-Skript nicht ausgeführt werden kann. Dies ist das Standardverhalten bei der Snapshot-Erstellung für Amazon Data Lifecycle Manager, wenn Vor- und Nach-Skripte nicht aktiviert sind. Wenn Sie Wiederholungen aktiviert haben, verwendet Amazon Data Lifecycle Manager standardmäßig nur dann absturzkonsistente Snapshots, wenn alle Wiederholungsversuche ausgeschöpft sind. Wenn das Vor-Skript fehlschlägt und Sie nicht standardmäßig absturzkonsistente Snapshots verwenden, erstellt Amazon Data Lifecycle Manager während dieser geplanten Ausführung keine Snapshots für die Instance.
Wenn Sie Snapshots für SAP HANA erstellen, sollten Sie diese Option unter Umständen deaktivieren. Absturzkonsistente Snapshots von SAP-HANA-Workloads können nicht auf dieselbe Weise wiederhergestellt werden.
-
Wählen Sie Standardrichtlinie erstellen.
- AWS CLI
-
So erstellen Sie die Snapshot-Lebenszyklusrichtlinie
Verwenden Sie den Befehl und fügen Sie die Parameter in ein. create-lifecycle-policyScripts
CreateRule
Weitere Informationen finden Sie in der API-Referenz für Amazon Data Lifecycle Manager.
$
aws dlm create-lifecycle-policy \
--description "policy_description
" \
--state ENABLED \
--execution-role-arn iam_role_arn
\
--policy-details file://policyDetails.json
Wenn policyDetails.json
einen der folgenden Aspekte beinhaltet, gehen Sie je nach Anwendungsfall wie folgt vor:
-
VSS-Backup
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key
",
"Value": "tag_value
"
}],
"Schedules": [{
"Name": "schedule_name
",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency
",
"Scripts": [{
"ExecutionHandler":"AWS_VSS_BACKUP",
"ExecuteOperationOnScriptFailure":true|false
,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
-
SAP-HANA-Backups
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key
",
"Value": "tag_value
"
}],
"Schedules": [{
"Name": "schedule_name
",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency
",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA",
"ExecuteOperationOnScriptFailure":true|false
,
"ExecutionTimeout":timeout_in_seconds (10-120)
,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
-
Benutzerdefiniertes SSM-Dokument
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key
",
"Value": "tag_value
"
}],
"Schedules": [{
"Name": "schedule_name
",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency
",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn
",
"ExecuteOperationOnScriptFailure":true|false
,
"ExecutionTimeout":timeout_in_seconds (10-120)
,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
Überlegungen zu VSS-Backups mit Amazon Data Lifecycle Manager
Mit Amazon Data Lifecycle Manager können Sie VSS-fähige Windows-Anwendungen (Volume Shadow Copy Service), die auf EC2 Amazon-Instances ausgeführt werden, sichern und wiederherstellen. Wenn für die Anwendung ein VSS-Schreiber bei Windows VSS registriert ist, erstellt Amazon Data Lifecycle Manager einen Snapshot, der für diese Anwendung anwendungskonsistent ist.
Amazon Data Lifecycle Manager unterstützt derzeit EC2 nur anwendungskonsistente Snapshots von Ressourcen, die auf Amazon ausgeführt werden, insbesondere für Sicherungsszenarien, in denen Anwendungsdaten wiederhergestellt werden können, indem eine bestehende Instance durch eine neue Instance ersetzt wird, die aus dem Backup erstellt wurde. Nicht alle Instance-Typen oder Anwendungen werden für VSS-Backups unterstützt. Weitere Informationen finden Sie unter Anwendungskonsistente Windows VSS-Snapshots im Amazon-Benutzerhandbuch. EC2
Nicht unterstützte Instance-Typen
Die folgenden EC2 Amazon-Instance-Typen werden für VSS-Backups nicht unterstützt. Wenn Ihre Richtlinie auf einen dieser Instance-Typen abzielt, erstellt Amazon Data Lifecycle Manager möglicherweise trotzdem VSS-Backups, aber die Snapshots sind unter Umständen nicht mit den erforderlichen System-Tags gekennzeichnet. Ohne diese Tags werden die Snapshots nach der Erstellung nicht von Amazon Data Lifecycle Manager verwaltet. Sie müssen diese Snapshots möglicherweise manuell löschen.
Geteilte Verantwortlichkeit für anwendungskonsistente Snapshots
Sie müssen Folgendes sicherstellen:
-
Der SSM-Agent ist installiert und wird auf Ihren Ziel-Instances ausgeführt up-to-date
-
Systems Manager verfügt über Berechtigungen zum Ausführen der erforderlichen Aktionen auf den Ziel-Instances.
-
Amazon Data Lifecycle Manager ist berechtigt, die Systems-Manager-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf den Ziel-Instances erforderlich sind.
-
Für benutzerdefinierte Workloads, wie z. B. selbstverwaltete MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, enthält das SSM-Dokument, das Sie verwenden, die richtigen und erforderlichen Aktionen zum Einfrieren, Leeren und Auftauen von I/O für Ihre Datenbankkonfiguration.
-
Die Zeiten für die Snapshot-Erstellung richten sich nach Ihrem Workload-Zeitplan. Versuchen Sie beispielsweise, die Snapshot-Erstellung für geplante Wartungsfenster einzuplanen.
Amazon Data Lifecycle Manager stellt sicher, dass:
-
Die Snapshot-Erstellung wird innerhalb von 60 Minuten nach der geplanten Snapshot-Erstellung initiiert.
-
Vor-Skripte werden ausgeführt, bevor die Snapshot-Erstellung initiiert wird.
-
Nach-Skripte werden ausgeführt, nachdem das Vor-Skript erfolgreich war und die Snapshot-Erstellung initiiert wurde. Amazon Data Lifecycle Manager führt das Nach-Skript nur aus, wenn das Vor-Skript erfolgreich war. Wenn das Vor-Skript fehlschlägt, führt Amazon Data Lifecycle Manager das Nach-Skript nicht aus.
-
Snapshots werden bei der Erstellung mit den passenden Tags versehen.
-
CloudWatch Metriken und Ereignisse werden ausgegeben, wenn Skripts initiiert werden und wenn sie fehlschlagen oder erfolgreich sind.