Servers

New

Add a server through the add server assistant. On the confirm page, you have the ability to use these settings as your server defaults.

Index

The Servers index page provides an overview of all active and inactive servers in your RightScale account across all deployments. The servers listed below are cloud instances that were launched from the context of a deployment using ServerTemplates. Instances that were not launched from a deployment will not be listed. For example, instances that were launched directly from an image (e.g. AMI) and instances that were launched in a server array. To view an exhaustive lists of all instances that have been launched or terminated regardless of whether they were launched from a deployment or AMI, go to Clouds -> Cloud/Region -> Instances.

Actions

• New Server - Add a server to a deployment.

- -

Inactive tab

The Inactive tab shows an archived list all servers that were successfully terminated or stopped. Once a server appears under the Inactive tab, you will no longer incur server usage charges. You can relaunch any terminated instance, as well as delete (remove it) from the list.

Active tab

The Active tab lists all active servers. Essentially, any server that has been launched in the RightScale Dashboard or API is considered an "active" server. However, it's important to understand that an active server is not always an operational server in the sense that it has an equivalent physical piece of hardware that's been incarnated at the cloud level. Also, you may not incur server usage charges even though it's an "active" server. (e.g. Spot instance types that are in the 'bidding' state.)

Show

View detailed information about your server.

Action Buttons

• Clone - Create a carbon copy of the current server configuration in your deployment. Cloning does not copy the actual data of a server, it only copies the configuration and description of that server as it's defined in the deployment.
• Move - Move a server to a specific/different deployment. Be careful when moving stopped or running servers. Alert escalations and inputs can be defined at the deployment level. Therefore, you may run into conflicts where a server may inherit incorrect input parameters or use a different alert escalation than expected. A running server will keep its current input parameters when it is moved to a different deployment. But, if the moved server is launched/relaunched from the new deployment, it will inherit any input parameters that are defined at the deployment level, when applicable, unless they are not overwritten at the server level. If a server is locked, it cannot be moved. If a deployment is locked, none of its servers can be moved.
• SSH Console - Open an SSH terminal into the server using an SSH client. By default, you will use Mindterm's universal client (Java applet). However, you can also use a natively installed SSH application when available. Set your SSH preferences under Settings -> User -> Preferences tab. If you are on a private cloud and opened up port 22 in the Security Group associated to your server, you will SSH into your public IP from the SSH Console. If you did not set up port 22 in your Security Group, or if you do not have a public IP, you will SSH into your private IP. If you have both a public and private IP, you can navigate to the server???s Info tab and select ???SSH into IP Address??? or ???SSH into private IP Address??? next to the IP address you would like to SSH into.
• Bundle - Bundle-up the instance. It creates a new image from the running instance (not available for free trial accounts). As a best practice, we recommend using ServerTemplates instead of bundling instances since images are static, whereas ServerTemplates provide a more flexible and configurable way for managing the lifecycle of your servers.
• Stop - The ability to stop a running instance is only supported by instances that were launched with an EBS-based AMI, otherwise this button will be hidden.
• Terminate - Terminate the server. Make sure that servers are successfully terminated, otherwise you will still incur associated server usage costs. You cannot delete a locked Server. (For AWS, you can also terminate a launched spot price instance type that's currently in the "bidding" state.)
• Start - The ability to start a stopped instance is only supported by instances that were launched with an EBS-based AMI, otherwise this button will be hidden.
• Reboot - Reboot the instance. If possible, you should always launch fresh new servers with your ServerTemplate instead trying to reboot a troublesome server. Remember, in the cloud you always want to "roll forward" instead of wasting time trying to troubleshoot a problematic server.
• Launch - Launch a fresh new server.
• Relaunch - When a server is relaunched, the current server is terminated and a new server is launched in its place. The new server will receive a new aws-id, private DNS name, and public DNS name, because it is a completely different physical machine. Relaunching a server is equivalent to terminating the existing running server and launching a fresh new server in its place, whereas a reboot will restart the same physical machine. When you relaunch a server, the configurations and inputs that are defined under the "Next" server will be used.

Server History Timeline Use the Server History Timeline bar to quickly select and view any of the most recent server sessions, the current server session, as well as see how all future (next) launches of that server will be configured. The tabs below reflect the selection in the timeline bar. Changes made to the "Current" server only apply to the current running server and will not persist to future server launches. However, changes made to the "Next" server do persist and will overwrite any configurations that are inherited from the template or deployment levels, such as input values. Click the History button to jump to the server's History tab and view an exhaustive history of all previous server sessions.

History tab

The History tab shows relevant details about the history of the server such as the cloud infrastructure's instance/server ID that was assigned to a launched server, as well as timestamps of launch/termination and overall runtime data.

Console Output tab

The Console Output tab shows generated meta-data, which is useful for troubleshooting. The host of an EC2 instance captures the console output and "posts" it to the EC2 management server from where it can be retrieved and displayed.

There are a few details you should know about the console output:

• The console output is posted a few minutes after a server is booted or shutdown. EC2 does not provide a running console output.
• Only the last 64KB of the console output is posted.
• If you reboot an instance, the console output will be posted twice: shortly after shutting down the OS and shortly after it comes up again.
• Posted console output is only guaranteed to be retained for one hour (so you may not be able to see the boot messages of an instance that was launched a long time ago).

Click the Reload button to observe the last output data, which includes the timestamp and output size. EC2 will be queried each time the button is clicked.

Volumes tab

The Volumes tab lists the server's Elastic Block Store (EBS) configuration settings. If the server is running, any volumes that are currently attached to the server will be listed. Any volumes or snapshots that will be used when the server is rebooted will also be listed. Volumes that are manually created and attached to a server using one of the actions below will not be deleted when the instance is terminated. Each volume must be deleted manually.

Action Buttons

• Attach Snapshot - When you attach a snapshot, a volume will be created from the snapshot and attached to the server. The volume's size will be
• Attach Volume - Attach an existing volume that's currently available (i.e. not attached to an operational server). You can only attach a volume that exists in the same availability zone as the server.
• Attach Blank Volume - Create and attach a blank volume. Specify the size of the volume in GB.

Audit Entries tab

View a real-time changelog of actions that were performed on your server. For example, running scripts, attaching EBS volumes, launching/terminating the server.

Scripts tab

The Scripts tab shows a consolidated list of all scripts (RightScripts and/or Chef Recipes) that are used by the server. You can only run scripts on the current operational server. You cannot add/remove RightScripts/Recipes on a running server. A server always reflects the scripts that are defined by its ServerTemplate. Therefore, if you launch a server using the HEAD version of a ServerTemplate and then add a RightScript to the HEAD ServerTemplate, the script will appear under the server's Scripts tab. Similarly, you can also change the server's ServerTemplate to change the scripts that are available for execution.

Operational Servers
When a script is run, the script will be executed on the running server. Typically, you will need to run a boot or operational script when input values have been modified and you need to pass those new input values to your running servers. In such cases, you need to execute the associated script that contains the input value. If the server is running, you can execute (run) any of the scripts on the server. In addition to running boot, operational, or decommission scripts, you also have the option of running "any script" on a server. You can also freeze software repositories at the server level. Similar to inputs, when you freeze software repositories at the server level, the changes will take precedence over frozen repositories that are defined at either the ServerTemplate or Deployment levels.

Stopped or Next Servers
When viewing the Next server, you can enable/disable RightScripts on the next server launch or relaunch. For example, you may want to disable a particular script from running during boot time. Or you may want to disable an operational script to prevent that action from being executed on the running server. However, you will not be able to re-enable or disable a script once a server has been launched. Disabled scripts will not be displayed in the list of scripts when viewing the current server.

Changes tab

The Changes tab shows a list of changed attributes that were either made to the server when it was active or inactive. For example, changes to a server's nickname, SSH key, or security group(s) will be shown. However, changes to frozen software repositories, alerts, or the ServerTemplate revision are not displayed. Whereas the Audit Entries tab displays a server's actions, the Changes tab only displays modifications to a server's attributes. The Changes tab is only shown for inactive servers.

Inputs tab

The Inputs tab shows the Input parameter settings for a server based on the selection in the History timeline bar. For previous server launches, you can see exactly how the inputs were configured when the server was terminated.

For a current (running) server, you might want to change its configuration. For example, you might need to run a script that will pass a different input parameter than what was originally inherited by the server at launch time. When you edit an input parameter for a running server, you must also execute the related script in order to pass the new value to the running server. Otherwise, it could lead to confusion and inconsistency. You always want your server's configuration to match the actual state of the server. As a best practice, you should only change a current server's inputs if you plan to execute the associated script.

It's important to understand that any changes that you make under the "current" server's Inputs tab will not persist to future server launches, as they only apply to the running server. If you want an input parameter to be preserved, you should either add it at the ServerTemplate level or under the Inputs tab of the "next" server.

Warning! Any inputs that are defined under a "next" server's Inputs tab will overwrite any input settings that defined at the Deployment or ServerTemplate levels. You should only define inputs at this level under special circumstances.

Action Buttons

• Edit - Edit the inputs of a "current" or "next" server definition.
• Copy Inputs - Copy the input parameters from an editable server definition. For example, if you're viewing a "next" server, you can copy input parameters from the "current" server and vice-versa. This feature helps you to keep input parameters settings consistent between the "current" and "next" server definitions.

Alerts tab

A list of alerts that are attached to the server. Alerts can be defined at the Server, ServerTemplate, or Server Array levels. You can either add a new alert or copy an alert from one of RightScale's predefined alerts, from a different server in one of your deployments, or from one of the private/imported ServerTemplates. Once you copy an alert over, you can edit and customize the alert for your own purposes without affecting the original alert. Alerts are not global.

Warning: Changes to an alert's configuration will take effect immediately. If the server is running, you may want to disable the associated server array unless you want the changes to take effect immediately. You also have the ability to change the status of the alerts. For example, if you want to prevent a server from voting for specific alert conditions that would affect autoscaling, you can temporarily disable (quench) some or all of the alerts for one hour or 24 hours.

Action Buttons

• New - Create a new alert specification on the current/next server.
• Copy Alert - Copy an alert specification from another Server, ServerTemplate, or from a list of default alert specifications defined by RightScale. Once an alert is copied, you can modify it accordingly.
• Enable All - Re-enable any disabled or quenched alerts.
• All 1hr off - Quench all alert specifications for one hour. After an hour, all alert conditions will be re-evaluated from the beginning (i.e. after time expires, the alert will not automatically reappear)
• All 24hr off - Quench all alert specifications for 24 hours. After 24 hours, all alert conditions will be re-evaluated from the beginning (i.e. after time expires, the alert will not automatically reappear)
• Disable All - Disable all enabled alerts. Alert specifications will no longer be evaluated and alerts escalations will no longer be called.

Info tab

The Info tab shows general information about the server, including all cloud-specific information. If a server is inactive, you can edit any of the server's configurations. Changes at the server level overwrite configurations that are otherwise inherited from the ServerTemplate or Deployment levels. However, if the server is active, you can only edit its ServerTemplate revision and Elastic IP. When you change the ServerTemplate revision of a running server, only the scripts and inputs of the new revision are made available to the running server. Therefore, if you change it to a newer revision that contains new/changed/deleted inputs, you will need to run the associated script to pass the new input values to the running server. However, since the server is already operational, you cannot change its machine image (AMI, RightImage). The ability to change a running server's ServerTemplate gives you the flexibility of "rolling forward" an operational server instead of shutting it down after you've launched new servers (with the new template revision) and switching over an Elastic IP. You can also add machine tags for metadata.

Warning: Be careful when changing a running server's Elastic IP address. You do not want to accidentally steal an Elastic IP from another frontend server or send traffic to the wrong server. Once an Elastic IP is assigned to a new server and has time to settle, all traffic will be routed to that server.

Is the server locked?
Similar to deployments, you can also 'lock' a single server to protect it from select user actions. For example, when an individual server is locked, it cannot be manually moved, terminated, rebooted, or relaunched. However, automated, alert-based actions will remain active (e.g. sending email notifications, running scripts). You will also still be able to Clone and SSH. You can only lock running (active) servers.

Monitoring tab

View real-time monitoring graphs of the running server. Whereas only a few graphs are visible at the Dashboard and Deployment levels, all of a server's graphs are viewable under its Monitoring tab. A wide variety of metrics are monitored. If there is a particular graph that you would like to monitor on a regular basis, click the graph's "Save" option to add it to the list of favorite graphs below. (You can also use the QuickMonitoring graphs.) Drag and drop any saved graphs to change the order. Any changes to the saved graphs are persistent. Graphical data is only shown if the monitoring daemon has been installed on the instance. To enable monitoring, you will need to Set up collectd.