Deploy an application with Amazon Launch Wizard for SQL Server on RHEL
Access Amazon Launch Wizard
You can launch Amazon Launch Wizard from the Amazon Launch Wizard
console
Deploy Amazon Launch Wizard on RHEL
The following steps guide you through a SQL Server application deployment with
Amazon Launch Wizard on the Red Hat Enterprise Linux (RHEL) platform after you have launched it
from the console. For SQL Server deployments on RHEL, you must use an instance type
built on the Nitro
System. EBS volumes are exposed as NVMe block devices on instances built
with the Nitro System. Device names that are specified for NVMe EBS volumes in a
block device mapping are renamed using NVMe device names
(/dev/nvme[[0-26]n1
). Launch Wizard deployments on RHEL do not support block
devices on Xen-virtualized instances.
-
When you select Choose application from the Amazon Launch Wizard landing page, you are directed to the Choose application wizard, where you are prompted to select the type of application that you want to deploy. Select Microsoft SQL Server, then Create deployment.
-
Under Review Permissions, Launch Wizard displays the Amazon Identity and Access Management (IAM) role required for Launch Wizard to access other Amazon services on your behalf. For more information about setting up IAM for Launch Wizard, see Amazon Identity and Access Management (IAM). Choose Next .
-
On the Configure application settings page, select the Operating System on which you want to install SQL Server — in this case, Red Hat Enterprise Linux.
-
Deployment model. Choose High availability deployment to deploy your SQL Server Always On application across multiple Availability Zones.
-
You are prompted to enter specifications for the new deployment. The following tabs provide information about the input fields.
-
When you are satisfied with your configuration selections, select Next. If you don't want to complete the configuration, select Cancel. When you select Cancel, all of the selections on the specification page are lost and you are returned to the landing page. To go to the previous screen, select Previous.
-
After configuring your application, you are prompted to define the infrastructure requirements for the new deployment on the Define infrastructure requirements page. The following tabs provide information about the input fields.
-
When you are satisfied with your infrastructure selections, select Next. If you don't want to complete the configuration, select Cancel. When you select Cancel, all of the selections on the specification page are lost and you are returned to the landing page. To go to the previous screen, select Previous.
-
On the Review and deploy page, review your configuration details. If you want to make changes, select Previous. To stop, select Cancel. When you select Cancel, all of the selections on the specification page are lost and you are returned to the service landing page. When you choose Deploy, you agree to the terms of the Note at the bottom of the page.
-
Launch Wizard validates the inputs and notifies you if you must update a specification.
-
When validation is complete, Launch Wizard deploys your Amazon resources and configures your SQL Server Always On application. Launch Wizard provides you with status updates about the progress of the deployment on the Deployments page. From the Deployments page, you can view the list of current and previous deployments.
-
When your deployment is ready, a notification informs you that your SQL Server application is successfully deployed. If you have set up an SNS notification, you are also alerted through SNS. You can manage and access all of the resources related to your SQL Server Always On application by selecting the deployment, and then selecting Manage from the Actions dropdown list.
-
When the SQL Server Always On application is deployed, you can access your Amazon EC2 instances through the EC2 console. You can also use Amazon SSM to manage your SQL Server Always On application for future updates and patches through built-in integration via resource groups.
Post-deployment cluster tasks
The Launch Wizard Pacemaker implementation includes three cluster nodes: primary, secondary, and configuration only. The primary node provides the Microsoft SQL Server for RHEL resource and the floating IP address. To ensure that the cluster operates correctly, some administrative tasks must be performed in a specific way. If these tasks are performed incorrectly, then Pacemaker may identify the activity as a resource failure and attempt to fail over the resources to the secondary node. If the resources are failed over to the secondary node, the cluster can remain in an unknown state, which can impact user access.
There are four primary tasks: Start Cluster,
Stop Cluster, Move
Resources, and Recovery. These tasks
must be carried out by a sudo user with an SSH connection to any of the cluster
nodes. Before performing any of these tasks, verify the cluster status using
pcs resource status --all
. This command returns all cluster issues.
All issues must be addressed prior to performing any administrative tasks.
Start cluster
-
Log in to a cluster node using a sudo user over an SSH connection.
-
Verify that all cluster nodes are available.
-
Verify cluster status using the following command:
pcs resource --all
.Address all issues before attempting to start the cluster.
-
Start all cluster nodes using the following command:
pcs cluster start --all --wait
. -
Verify that the cluster has started using the following command:
pcs resource --all
.The output provides information about the cluster nodes and cluster resources. All cluster nodes should be online and all resource agents should be visible and allocated to their assigned cluster nodes.
-
Verify that the availability group listener is available by pinging the floating IP address.
Manually move cluster resources
-
Log in to a cluster node using a sudo server over an SSH connection.
-
Verify that all cluster nodes are available.
-
Verify cluster status using the following command:
pcs resource --all
.Address all issues before attempting to start the cluster.
-
Run the following command:
pcs resource move
.<RESOURCE_NAME>
-master<NODE_NAME>
--forceThis command moves the resource agent to
<NODE_NAME>
and starts the resource. All cluster constraints will be applied. If the Microsoft SQL Server resource agent is moved, then the availability group listener will follow. -
Verify cluster status using the following command:
pcs resource --all
.The resource that was moved should be located on the
<NODE_NAME>
. -
Clear temporary constraints using the following command:
pcs resource clear
.<RESOURCE_NAME>
Stop cluster
-
Log in to a cluster node using a sudo server over an SSH connection.
-
Verify that all cluster nodes are available.
-
Verify cluster status using the following command:
pcs resource --all
.Address all issues before attempting to start the cluster.
-
Stop the cluster using the following command:
pcs cluster stop --ALL
. This will gracefully shut down all of the cluster nodes. -
Verify the shut down status using the following command:
pcs status --all
.This command should return that the cluster is no longer running.
Recovery
If a node is restarted from the operating system or the Amazon Web Services Management Console, the Pacemaker node and its related services will not automatically start. This prevention protects the high availability database replicas from split-brain corruption.
The following steps are required to restore the cluster to normal operations.
-
Log in to a cluster node using a sudo server over an SSH connection.
-
Determine the node that was restarted using the following command:
pcs resource --ALL
. The restarted node will be offline. -
Verify cluster status using the following command:
pcs resource --all
.Address all issues before attempting to start the cluster.
-
Start the restarted node using the following command:
pcs cluster start --
.<NODE_NAME>
-
Verify cluster status using the following command:
pcs resource --all
.Address all issues before attempting to start the cluster.
-
If the restarted node is the primary node of the cluster, then the Availability Group resource must be returned to the primary node.
-
Remove all temporary constraints using the following commands:
pcs resource clear
and<AG_RESOURCE>
pcs resource clear
.<AG_LISTENER>
-
Run the following command:
pcs resource move
.<RESOURCE_NAME>
<PRI_NODE_NAME>
--forceThis command moves the resources to
and starts the resource. Any cluster constraints are applied. In this scenario, if the Microsoft SQL Server resource agent is moved, then the availability group listener follows.<PRI_NO_NAME>
-
Verify cluster status using the following command:
pcs resource --all
. The restarted node will be located on
.<PRI_NO_NAME>