Copyright (c) 2006-2014 MindTouch Inc.
This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).
At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.
A complete copy of the MSA is available at http://www.mindtouch.com/msa
To run the Zend Standard or High Availability Solution Pack Macro to create a preconfigured environment in a RightScale account.
Table of Contents
The Macro is designed to build an environment in the AWS US-East region. The Macro will not automatically launch any Servers; it simply creates and configures the environment accordingly.
By default, the application servers will retrieve their application at boot time using a RightScripts. If you are using the Zend High Availability Solution Pack and wish to use the Zend Cluster Manager to deploy your application code instead, you will need to make the following changes:
Below is an overview diagram of the architecture that the Macro will create upon execution. The following instance sizes are used by default for the setups below.
When the Zend (application) Servers are launched, they will automatically connect to the Zend Cluster Manager Server and Load Balancer(s) at boot time. Once the connections have been established, you can log into the Zend Cluster Manager Server's console to view all collected session data for each Zend (application) Server. Four ServerTemplates will be used to configure the Deployment. Zend ServerTemplates will be used to configure the Zend (application) Servers and Zend Cluster Manager Server. RightScale ServerTemplates will be used for the Load Balancer and Database Servers.
The key difference between the High Availability (HA) and Standard Solution Pack is that the HA pack leverages two load balancers instead of one and also has a Zend Cluster Manager Server.
Here is a breakdown of the components that are created/imported/cloned when the Macro is run.
Go the MultiCloud Marketplace (Design -> Macros) and import the solution pack into your RightScale account. Depending on how you were granted access to the solution pack, you may find it listed under the 'Shared' category.
Once you've subscribed to the Macro, you will be redirected to its show page in your RightScale account (Design -> Macros).
Keep the default selections and click the Run button. The screenshot below is an example of the "High Availability" Solution Pack. If you are running the "Standard" version, the list may be different.
First, you will be prompted to select a cloud (EC2 Region). All servers will configured to launch into the selected cloud. Enter the number for the selected cloud.
Before the macro can create the servers in your new deployment, it must first create the necessary cloud resources that are required in order to create and define a server. The Macro will create these cloud resources based on the name that you specify and then use them to define the various servers in the deployment.
Next, the macro will create all of the required cloud resources (e.g. security groups, SSH keys, etc.). You will be prompted to provide names for the security groups that will be used by the created servers. It's recommended that you use the suggested names for names for each cloud resource because it will make it easier to find the related cloud resources and understand the supporting documentation, which assumes the use of the suggested names.
You will also be prompted to provide a nickname for the new Deployment that will be created. (e.g. Zend HA)
If you are running the Zend HA solution pack, a few Elastic IPs will be also be created. Keep the default names when prompted. (e.g. LB1-Zend-HA)
Once you see the "Macro executed successfully!" message you'll be redirected to the deployment that the macro just created for you.
You'll see several servers in your deployment. Notice that a server array was also created and attached to the Deployment, which will be used for autoscaling the Application Tier of Zend Servers. (e.g. zend server array)
You will need to manually create the following RightScale Credentials, which you will later use when you configure the Inputs for your Deployment. If you've previously created some of these Credentials for previous Deployments, you may need to create another Credential if you want a different value to be used. (e.g. DBADMIN_PASSWORD_ZEND)
The Macro created new Elastic IPs. You will need to create the following DNS A Records with your DNS Provider.
* Only applies to the HA version.
For instructions on how to set up DNS Records with a supported DNS provider (e.g. DNSMadeEasy), follow one of the Domain Setup tutorials.
By default, the macro will create database servers that are configured to launch 'm1.small' instance types. It's recommended that you use an 'm1.large' instance type to increase database performance.
To change the instance type from a "small" to a "large" you will need to update each database server's configuration.
There are a couple of different ways that you can set up your database tier depending on whether or not you have an existing backup (set of snapshots) that you want to use instead of creating the database from a dump file.
The next step is to define any missing Input parameters at the Deployment level so that your Servers will be launched with the correct information. As a best practice, you should always define inputs at the Deployment level for the ones that you're not inheriting from the ServerTemplate level so that the same input parameters will be used by all of your Servers.
Note: Several inputs are defined at the ServerTemplate level and reference Credentials that you should have created in a previous step. If a different value needs to be used, you must override the input setting so that the appropriate value is either passed as Text or a Credential.
To define values for the missing inputs, go to your deployment's Inputs tab. Hover over the info icon for a tooltip description for the input.
* Only applies to the HA version.
Before you launch your Load Balancer server, you should make sure that you're launching the Server in the proper cloud/region and availabilty zone. Typically, you will want your load balancer to be in the same cloud/region and availability zone as your application and master database servers to reduce data transer costs and minimize latency.
Note: This step only applies to the HA version. If you are using the Standard version, you can skip this step.
Go to your Zend Deployment (Manage -> Deployments -> YourDeployment -> Servers tab) and launch the Cluster Manager server.
Note: If you are using the HA solution pack, both load balancers and Zend Cluster Manager Server must be operational before you launch any Zend Application Servers.
Go to your Zend Deployment (Manage -> Deployments -> YourDeployment -> Servers tab) and launch the Zend (Application) Server.
At this point you have a functional deployment with all three tiers (load balancer, application, database). To configure your setup for autoscaling the application tier, you can enable the server array. The server array is currently configured to be disabled (default). You must manually enable the server Array and make it active so that autoscaling can take place. The server array is designed to have a minimum count of two instances, so when you enable the array, two new instances will soon be launched into the array.
Note: The voting tag that will be used for autoscaling purposes is 'zendarray' for both solution packs. If you are running both solution pack deployments in the same account, you will experience autoscaling problems because both arrays will be using the same voter tag. If you plan to run both solution pack deployments in the same account at the same time, you will need to modify your alert specifications and voter tag so that each array will be using a different voter tag for autoscaling purposes.
This step only applies to Zend HA solution pack deployments.
Once the Zend (application) servers are operational, you can log into the Zend Cluster Manager (CM) web interface to verify that the servers were registered properly.
Using the DNS A Record that you created for the Zend Cluster Manager to build a URI similar to the following in order to access the Zend control panel:
or use the CM's public DNS link to construct a URI like the following:
Once you log in with your password (ZEND_GUI_PASSWORD), you should see all running Zend (application) servers.
At this point, you should have a fully functioning Zend Server environment running in the cloud.
|Glossary | 用語 | 용어||Site Map | Site Help||Community||Corporate Site||Get Support||Dashboard Login|
|Doc Feedback||Product Feedback||Resources||MultiCloud Marketplace||Forums|
© 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.