Add a server through the add server assistant. On the confirm page, you have the ability to use these settings as your server defaults.Manage > Servers > New Server
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.
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.Manage > Servers > Index > Inactive 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.)Manage > Servers > Index > Active tab
View detailed information about your server.
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.Manage > Servers > Show
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.Manage > Servers> Show > History 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:
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.Manage > Servers > Show > Console Output 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.
View a real-time changelog of actions that were performed on your server. For example, running scripts, attaching EBS volumes, launching/terminating the server.Manage > Servers > Show > Audit Entries 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.
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.
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.Manage > Servers > Show > Changes 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.
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.
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.
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.Manage > Servers > Show > Monitoring tab
© 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.