Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Tutorials > Database Manager for Microsoft SQL Server Setup (Infinity)

Database Manager for Microsoft SQL Server Setup (Infinity)

Prerequisites

  • You must log in under a RightScale account with 'actor,' 'designer', 'security_manager,' and 'library' user roles in order to complete the tutorial.
  • For Amazon EC2 and CloudStack-based clouds, you must have a security group defined with TCP port 3389 open for Remote Desktop Connection (RDC), and any other ports required by the server (for example, the default SQL Server port, TCP port 1433, and the mirroring listener port—5022 by default), for the required security groups and IP addresses. Also remember that for clouds other than Amazon EC2, Windows Firewall is turned on by default.
  • In synchronous-mirroring environments, it's strongly recommended that your principal and mirror servers are located in the same AWS region / availability zone / datacenter in order to communicate.
  • We strongly recommend that you set up credentials for password values and any other sensitive data included as inputs. See "Create Credentials" section below.
  • This tutorial assumes that you are attaching a SQL Server database (or databases) using either a backup (.bak) or database (.mdf) file stored in a Remote Object Storage (ROS) container such as Amazon S3, Rackspace Cloud Files, Windows Azure Storage, or SoftLayer storage). Once you have set up your SQL database on a cloud server and taken a backup of the database, you can restore the SQL Server databases from a previous backup that contains the appropriate lineage tags for proper retrieval.

Overview

This tutorial describes the steps for launching either a standalone Microsoft SQL server(s) in a cloud or a mirrored setup consisting of a Principal and Mirror database server.

Steps

Create Credentials

Prerequisite: Requires 'actor' user role privileges in the RightScale account.

In order to securely pass sensitive information to a script at runtime, you can use Credentials as a means of variable substitution. Later in this tutorial you will select these credentials when you define your inputs. If you will use Remote Storage (Amazon S3, RackSpace CloudFiles, Windows Azure Storage, or SoftLayer Object Storage), you should set up a pair of credentials like the following and reference them when configuring inputs.

For more information on setting up credentials, see Create a New Credential.

  • WINDOWS_ADMIN_PASSWORD - Set a new password for the local Administrator account that will replace the initial password that's generated at boot time. You will use this password to create a Remote Desktop connection (RDP session) into the server when you login with the 'Administrator' username. It's suggested that you name the credential accordingly. 
  • SQL_SERVER_USER - A SQL database user with database login privileges for the specified database.
  • SQL_SERVER_PASSWORD - The password for the SQL database user with database login privileges for the specified database.
  • DNS_USER* - Username that's used to log into your DNS provider and access your DNS records.
  • DNS_PASSWORD* - Password for DNS_USER.

If you use Amazon Route 53 as your DNS provider, you do not need to set up separate DNS user name and password credentials because your AWS credentials are used for authentication purposes. 

Depending on your cloud provider and backup storage selections, you may need to create additional credentials.

Amazon Snapshots

If you are using Amazon to make snapshot/binary backups of your database, you will need to use the following credentials. Fortunately, these credentials were automatically created when you added your AWS credentials to the RightScale account.

Note: These credentials are not listed under Design > Credentials.

  • AWS_ACCESS_KEY_ID - Amazon access key ID for authentication.
  • AWS_SECRET_ACCESS_KEY - Amazon secret key corresponding to AWS_ACCESS_KEY_ID.


Rackspace Cloud Files

If you are using Rackspace Cloud Files for storing binary database backups, you will need to create the following credentials.

  • RACKSPACE_USERNAME - The username used to log into Rackspace's Cloud Control Panel. Use this credential for the "Backup Primary User" and/or the "Secondary Backup User" input if you are using Rackspace Cloud Files for primary and/or secondary backups. 
  • RACKSPACE_AUTH_KEY - The Rackspace account API key corresponding to RACKSPACE_USERNAME. Use this credential for the "Backup Primary Secret" and/or the "Secondary Backup Secret" input if you are using Rackspace Cloud Files for primary and/or secondary backups.

 

Windows Azure Storage

For Windows Azure Storage, create the following credentials:

  • AZURE_USERNAME - Windows Azure account username.
  • AZURE_PASSWORD - Windows Azure account password.

 

SoftLayer Object Storage

For SoftLayer, create the following credentials:

  • SOFTLAYER_USERNAME - SoftLayer account username.
  • SOFTLAYER_API_KEY - SoftLayer API key.

Upload the Database Dump File

The ServerTemplate contains scripts that can retrieve a Microsoft SQL database backup file from a Remote Object Storage (ROS) location such as an Amazon S3 bucket, Rackspace Cloud Files, Windows Azure Storage, or SoftLayer storage. Create a new bucket/container and upload your database backup file. You can either restore the database using a SQL backup file (.bak) or attach an existing database file (.mdf). The file can remain a 'private' object because your cloud credentials can be used (as inputs) for authentication purposes to retrieve the file. 

Warning! The filename of the backup file cannot contain a dash (-) in its prefix name. For example, if your dump file is named, 'my-app-201205030022.gz', you must manually rename it to be 'my_app-201205030022.gz' where you use an underscore (_) to replace the dash, otherwise the script (do::do_dump_import) that imports the database dump file into the instance will fail.


If you are setting up a database server for testing purposes and need a sample SQL backup file to complete the tutorial, you can use the following .bak file:

Create a Database Server

Follow these steps to add a database server to the deployment.

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the Database Manager for Microsoft SQL Server (v13.1) ServerTemplate into your RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment for the new server.
  5. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new database server (e.g., sql-db1). Do not include "primary" or "mirror" in the name, because a database server's role can change in the future.
    • Select the appropriate cloud-specific resources (e.g. SSH Key, Security Group, etc.) that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters/zones, select a specific zone. Later, when you create the other database server you will use a different datacenter/zone to ensure high-availability. For more information, see Add Server Assistant.
    • Important! If you are not using volumes to store the database, you must select an instance type that has disk space that's at least twice as large as your database because LVM snapshots are performed locally on the instance before they are gzipped and saved to the specified ROS location. Also, although these ServerTemplates will work with any instance size, you may experience degraded performance with small instance sizes (such as EC2 micro, Rackspace 256MB etc) due to lack of system resources. We do not recommend smaller instance types for production use.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Configure Inputs

The next step is to define the properties of your database server or servers by entering values for inputs. It is simplest and best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Understanding Inputs.

The inputs that you need to provide values for will depend on which options you're going to use. The ServerTemplate is very flexible and supports a variety of different configurations. You will need to provide the necessary values as inputs based on which options you want to use.

Set Inputs at the Deployment Level

Go to the deployment's Inputs tab (Manage > Deployments > your deployment) and click Edit.

Although you can enter text values for all missing inputs, it's strongly recommended that you set up credentials for passing sensitive information to scripts such as passwords or any other sensitive data.

BACKUP

By default, the server will be configured to take continuous backups of the SQL database. Backups will either be saved as snapshots (if volumes and snapshots are supported by the cloud) or as backup files (.bak) to an ROS location such as an Amazon S3 Rackspace Cloud Files, Windows Azure, or SoftLayer storage. If you are setting up the SQL database with this ServerTemplate for the first time, you can either use an existing database (.mdf) or backup (.bak) file stored in an ROS container. If you are using the provided example, provide the appropriate inputs to use the backup file (DotNetNuke.bak).

Input Name
Description
Example Value
BACKUP_FILE_NAME

The name of the database backup file that you previously uploaded to an ROS container.  (e.g. sql-database.bak)

If you are going to use a database file (.mdf), leave this field empty and use the MDF_FILE_NAME input instead.

For the provided sample file use:

text:  DotNetNuke.bak

BACKUP_METHOD

Select the type of backup storage that will be used for taking backups of the database.

  • Snapshots - Volume snapshots such as Amazon's Elastic Block Store (EBS).
  • Remote Storage - The remote object storage type specified in REMOTE_STORAGE_ACCOUNT_PROVIDER (Amazon S3,  Rackspace Cloud Files, Windows Azure Storage or SoftLayer Object Storage), using the bucket or container specified in REMOTE_STORAGE_CONTAINER.
text:  Snapshots
DB_BACKUP_KEEP_DAILY, _LAST, _MONTHLY, _WEEKLY, _YEARLY
 

If you are using snapshots (BACKUP_METHOD=Snapshots) to create database backups, you can use these inputs to specify the preferred backup policy. 

Input is ignored if you are using 'Remote Storage' for BACKUP_METHOD.

 
MDF_FILE_NAME

The name of the database file that you previously uploaded to an ROS container.  (e.g. sql-database.mdf)

If you are going to use a database backup file (.bak), leave this field empty and use the BACKUP_FILE_NAME input instead.

text:  sql-database.mdf

Cloud

In order to create volumes or retrieve objects such as a database or backup file from an ROS container, you must provide the required cloud credentials for authentication purposes.

Input Name
Description
Example Value

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Specify valid cloud credentials to retrieve the file from an Amazon S3 bucket.

cred:  AWS_ACCESS_KEY_ID

cred:  AWS_SECRET_ACCESS_KEY

Database

Important!
If you are configuring a mirrored setup (consisting of a Principal and Mirror server) and you want to launch the Mirror server in a different availability zone as the Principal server, you must use the 'Remote Storage' option for the INIT_MIRRORING_METHOD input.

Input Name
Description
Example Value
DATA_VOLUME_SIZE

The size of each volume that will be used store the SQL database.  For example, if the NUMBER_STRIPES input is '2' and you specify a DATA_VOLUME_SIZE of '5', two 5-GB volumes are created. It's recommended that you specify a large enough value that provides enough space for the database to grow over time and provide optimal r/w performance.

WarningIf your are deploying on a CloudStack-based cloud that does not allow custom volume sizes, enter a predefined CloudStack volume size (e.g., 'Small' or 'Large') rather than a numeric value here.

text:  10
DB_LINEAGE_NAME The lineage of the database backups. This is a string that is used to track all backups in a certain 'set', usually deployment wide. Ex: mymssqlserver text:  LineageName
DB_NAME

Enter the name of the default database to assign to the created SQL Server login. This value is not an arbitrary value. The name of the database is already set. If there are multiple databases, you can list a comma-separated list of all the database names. Ex: DatabaseName

text:  mydb

For the provided sample file use:

text:  DotNetNuke

INIT_MIRRORING_METHOD

The method for setting up a SQL database mirroring session between two servers. A backup (.bak) of the database and a self-signed certificate are used to authenticate a mirror session between a principal and mirror database server. If you want to launch the mirror in a different availability zone as the principal server, you must use an ROS location. If the cloud supports volumes and you want to launch the mirror in the same availability zone as the principal, select the 'Volumes' option.

  • Volumes (default) - A separate volume is used to transport the database backup file and certificate between the principal and mirror servers. If you select this option, both the Principal and Mirror servers must be launched into the same availability zone.
  • Remote Storage - An ROS container is used to store and transfer the database backup file and certificate between the principal and mirror servers. Select this option if you want to launch the Principal and Mirror servers into different availability zones.
text:  Volumes
LOGS_VOLUME_SIZE

Size of volume (in GB) for storing log files. Ex: 1

text:  1
NUMBER_STRIPES

If the cloud supports the use of volumes, you can create a drive (e.g. D:\) that consists of a stripe of volumes. This input applies to both the data and log drives. If you do not want to use a stripe of volumes, keep the default setting. (Default: 1)

WarningYou can set this to a numeric value between 1 and 5 when launching your server in the Amazon EC2 cloud; however, do not set it to values greater than 2 for CloudStack-based servers. This restriction is due to a difference in the quantity of block devices supported for CloudStack-based clouds.

For Windows Azure, make sure you specify a value that is supported by the selected instance type. The default instance type for the MCI is a 'medium' which supports a maximum of 4 volumes. If you choose to use a stripe, you will need to select a larger instance type based upon the total number of volumes that are required. For example, the total number of volumes equals the NUMBER_STRIPES * 2 (data and log volumes) plus an additional volume if you are using 'Snapshots' for the INIT_MIRRORING_METHOD.

See How many disks can I attach per Azure virtual machine size?

 

text: 1

DNS

Input Name Description Example Value
DNS_DOMAIN_NAME

If you are using a DNS service provider that references records by a FQDN instead of an string ID, use this input to specify the fully qualified domain name that points to the standalone or principal database server. (e.g. my-principal.example.com)

Examples:

  • DynDNS:  my-principal.example.com  (FQDN)
text:  my-principal.example.com
DNS_ID

If you are using a DNS service provider that references records by a unique string ID, use this input to identify your standalone or principal database server to your DNS provider. See Deployment Prerequisites for more information.

Examples:

  • DNS Made Easy:  1234567  (Dynamic DNS ID)
  • Rackspace Cloud DNS (US):  a1234567  (Dynamic DNS ID)
  • Rackspace Cloud DNS (UK):  a1234567  (Dynamic DNS ID)
  • Amazon Route53:  Z3DSDFSDFX  (Hosted Zone ID)
text: 1234567
DNS_IP_ADDRESS IP address to update the DNS record. Type specific IP address or select whether to use public or private IP address of the current instance. Ex: 1.2.3.4 text: Public IP
DNS_PASSWORD

The password used to log into your DNS provider. 

  • DNS Made Easy - DME Password
  • DynDNS - DynDNS Password
  • Amazon Route 53 - AWS Secret Access Key
  • Rackspace Cloud DNS - Rackspace Password
cred:  DNS_PASSWORD
DNS_SERVICE

Select the DNS provider that will be used to update the DNS record of the principal database server.

  • DNS Made Easy
  • DynDNS
  • Rackspace Cloud DNS (US region)
  • Rackspace Cloud DNS (UK region)
  • Route53
text:  DNS Made Easy

DNS_USER

The username used to log into your DNS provider. 

  • DNSMadeEasy - DME Username
  • DynDNS - DynDNS Username
  • Amazon Route 53 - AWS Access Key ID
  • Rackspace CloudDNS - Rackspace Username

cred:  DNS_USER

OPT_USE_PUBLIC_IP Defines whether or not a mirror database server will use the public (not private) IP address to connect to the principal database server.
  • True - Use public IP address for mirroring connection
  • False - Use private IP address for mirroring connection
text:  False

 

Remote Storage
Input Name Description Example Value
REMOTE_STORAGE_ACCOUNT_ID The Account ID or Name of the Remote Storage account which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. cred: AWS_ACCESS_KEY_ID
REMOTE_STORAGE_ACCOUNT_PROVIDER The remote object storage provider where your database file is stored,select appropriate provider from the dropdown. text:Amazon_S3
REMOTE_STORAGE_ACCOUNT_SECRET The Secret Key or Password of the Remote Storage account which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. cred: AWS_SECRET_ACCESS_KEY
REMOTE_STORAGE_CONTAINER

If retrieving from an Remote Storage container, specify its name here. If retrieving from an S3 bucket that does not belong to an Amazon account registered under your current RightScale account, you must ensure that the file is public (set to "public-read" at a minimum, in the RightScale Dashboard S3 Browser).

Warning: If BACKUP_METHOD is set to 'Remote Storage' and the S3 bucket or Cloud Files container used for backups differs from the one where your database file is stored, ensure that you change this value back to your backup container, if needed, after running this script.
text: mssqldatabases

SYSTEM

Input Name
Description
Example Value
ADMIN_PASSWORD

Set the new password for the local Administrator account. The password must satisfy Window's minimum requirements for a Windows administrator password, otherwise the random password that is generated for you at boot time (located under the server's Info tab,'Initial Admin Password' field) will be used instead. The password should be at least 7 characters long with at least one upper case letter, one lower case letter and one digit. 

When you RDP into the server, you will use this password to log in as the Windows 'Administrator' user.

It's strongly recommended that you use a credential to hide this value. However, anyone who needs to log into the server will need to know the actual value.

cred:  WINDOWS_ADMIN_PASSWORD  
INSTANCE_ID Used when making requests to Amazon EC2 cloud. For more information, see Environment Inputs. env: INSTANCE_ID
SYS_WINDOWS_TZINFO

Sets the system timezone to the timezone specified, which must be a valid Windows timezone entry. You can find a list of valid examples in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones". Some examples have been provided in the dropdown, which you may override if you do not see your timezone listed.

text: GMT Standard Time

Launch a Standalone Database Server

After configuring your inputs, launch the database server that will serve as either the standalone or principal server.

  1. Go to the deployment's Servers tab and launch the database server.
  2. When you view the input confirmation page, make sure the database server's mode is set to 'Standalone' mode. If you are setting up a mirrored Principal-Mirror setup, you will later run an operational script on this server that will change its mode to be a Principal.

DATABASE

Input Name
Description
Example Value
SERVER_MODE
Select the databaser server's role/mode. 
  • Standalone (default)  
  • Principal
  • Mirror
text:  Standalone
  1. If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process.
  2. Click the Launch (not Save and Launch) button at the bottom of the input confirmation page. 
  3. (Optional)  If you are launching a server in a cloud that uses volumes (e.g. AWS) you can go to the server's Volumes tab once it's operational to view the volumes that were created for the database server.  

screen-volumes-v1.png

Load the Database

The next step is to load the database onto the server by either using a backup (.bak) or database file (.mdf) from an ROS container.

  1. Go to the "current" server's Scripts tab.
  2. Run the appropriate operational script depending on the type of file.
    • For a backup file (.bak), run the DB SQLS Restore database from local disk / Remote Storage script.
    • For a database file (.mdf), run the DB SQLS Attach database from disk local disk / Remote Storage script.
  3. Provide values for the appropriate inputs depending on whether you're going to load the database from either a backup or database file.
  4. (Optional) Check the server to verify that the database was properly loaded. Click the server's RDP button to open up a Remote Desktop Connection to the instance. Navigate to Start > All Programs > Microsft SQL Server 2008 R2 > SQL Server Management Studio. (When asked to connect to the database, click Connect.) You should see the imported database listed under the "Databases" section.

screen-ShowDotNetNuke-v1.png

Create a Database Backup

The next step is to create your first backup of the database, which adds a set of tags (such as the lineage name) to the backup file. The tags are used by the ServerTemplate's scripts to properly locate and retrieve backups for initial setups and database restorations.

  1. Go to the "current" server's Scripts tab.
  2. Run the DB SQLS Backup Data and Log volumes operational script. If you are using volumes, a snapshot of the data and log volumes will be created and properly tagged. If you are not using volumes, a backup file (.bak) will be saved to the specified ROS location (REMOTE_STORAGE_CONTAINER).

Update DNS Record

Assuming that application servers or clients in your environment will access your principal or stand-alone SQL Server using a fully qualified domain name (FQDN) rather than IP address, update the DNS record (that points to the standalone/principal database server) with your DNS provider. 

  1. Go to the "current" server's Scripts tab.
  2. Run the DNS Register IP operational script. Note: You should have set the required inputs for the script at the deployment level before you launched the server. 
  3. (Optional) Check the DNS record to make sure it was updated with the expected IP address. If you set the DNS_IP_ADDRESS input to 'Private IP' (default) the DNS record should match the instance's Private IP Address under the "current" server's Info tab because you typically want to IIS application servers to connect to the database over the private network.


screen-DNS_Update-v1.png

Set up a SQL Mirroring Configuration with a Principal and Mirror Server

Important!  If you only want a standalone SQL database server your configuration is complete. However, if you want to set up a mirrored SQL configuration that contains a dedicated principal and mirror database server for high-availability purposes, please follow the remaining steps.

Change Server from Standalone to Principal Mode

The first step is to change the existing database server from "standalone" to "principal" mode.

  1. Go to the "current" server's Scripts tab.
  2. Run the DB SQLS Init principal operational script. 

Launch the Mirror Database Server

Next, launch a new server that will become a mirror of the principal server.

If you are setting up a synchronous mirrored SQL Server environment, you must launch another SQL database server that will act as a "mirror" of the "principal" server. Ignore this step if you are only setting up a stand-alone SQL Server environment.

  1. Clone the 'principal' database server.
  2. Rename the cloned server. (e.g. db2)  Note: Do not put "mirror" in the name because you do not want the server's name to cause confusion if you ever need to promote the mirror to become the new principal database server.
  3. (Recommended)  If possible, change the server's availability zone to promote high availability. Note: You can only use this option if you're using Remote Storage as the method for setting up a mirroring configuration. (INIT_MIRRORING_METHOD = text: Remote Storage) 
  4. Before you launch the server, make sure that first backup snapshot is 100% complete. The mirror server will use the backup file to restore the database before it starts synchronizing with the principal server.
  5. Launch the server. (You do not have to wait for the principal server to be operational before you launch the mirror server.)
  6. When you view the input confirmation page, change the database server's mode to 'Mirror' mode. 
DATABASE
Input Name Description Example Value
SERVER_MODE

Since you already have a 'Principal' server running, set this input to 'Mirror'.

text:  Mirror
  1. If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process.
  2. Click the Launch (not Save and Launch) button at the bottom of the input confirmation page. 
  3. Once both servers are operational, you should have a mirroring configuration for the SQL database. Machine tags are used to clearly identify the "Principal" and "Mirror" servers. Note: You can only have a single mirror server.

screen-PM_Servers-v1.png

  1. (Optional) Check the servers to verify that you have a synchronous mirrored SQL Server environment. For example, you can RDP into the principal server. Open "SQL Server Management Studio" and under the "Databases" section you now see that the database is the "principal" server in a synchronized setup.
    screen-SQL_Synchronized-v1.png

Create a SQL User

Note: If you are only setting up a standalone SQL database server, you can skip this step. 

If you are going to connect an IIS application server to the database, create a SQL user. Application servers will access the database using the created SQL user's username and password. If you want to use credentials to hide the actual username and password values, create appropriately named credentials prior to running the script below.

  1. Run the DB SQLS Create login operational script
Database
Input Name
Description
Example Value
DB_NAME

The name of the SQL database for which you are creating a user.

For the provided sample file use:

text:  DotNetNuke

DB_NEW_LOGIN_NAME

If an IIS application server will connect to this database server, you can create a SQL database user and password with database login privileges for the specified database. The IIS web application will use the created SQL user to access the database. 

After the server is operational, run the 'DB SQLS Create login' script to create the SQL database user. 

Note: You can also create a user with a script in the IIS application ServerTemplate. 

text:  dbuser

cred: SQL_SERVER_USER

DB_NEW_LOGIN_PASSWORD

 

Password of the SQL database user (DB_NEW_LOGIN_NAME). 

Note: Password must meet standard Windows 2008 server password complexity requirements. It should be at least 7 characters long with at least one upper case letter, one lower case letter, and one digit. 

text:  4MicroSoft!

cred: SQL_SERVER_PASSWORD

Optimize Tempdb System Database (Recommended)

Since the size, recovery model, and growth settings for the SQL Server tempdb system database can impact server performance, you should configure the database according to Microsoft's optimization recommendations, described in the Microsoft Developer Network (MSDN) article Optimizing tempdb Performance.

To configure these optimization settings automatically, run the DB SQLS Configure TempDB operational script on the standalone or principal server, which will:

  • Change the tempdb database's recovery model to 'Simple'
  • Change the autogrowth settings for the database and log files to autogrow by 10% (unrestricted growth)
  • Create one tempdb data (.mdf) file per virtual core (CPU) on the server, based on Microsoft's configuration recommendations. Use the OPT_TEMPDB_DATAFILE_SIZE input to specify initial file sizes for your data files, if needed. If you set this input to 'Ignore,' data file sizes default to 1 GB.

Next Steps

Launch IIS Application Servers

To launch IIS application servers that will connect to the Microsoft SQL database server, see the 3 Tier Deployment Setup (IIS and SQL) tutorial.

Safely Shutdown Database Servers

Follow the steps below to properly shutdown a SQL database server. 

  1. If the database server is using volumes for data storage, Go to the server's Inputs tab and change the 'DISABLE_SAFETY' input to 'text: off' by using the override dropdown option. If volumes are not being used, proceed to Step 3.
  2. Go to the server's Scripts tab and run the 'DB SQLS DISABLE SERVER - backup, detach and delete volumes' script. The server will be terminated and the previously attached volumes will be detached and deleted.
  3. Click the server's Terminate button.
You must to post a comment.
Last modified
09:25, 18 Jun 2013

Tags

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.