To set up a Solr application server in a cloud environment.
The Solr Tomcat App Server ServerTemplate configures a combined Tomcat and Apache application server. It creates an HTTP virtual host (vhost) and forwards requests to the specified application port to serve a Solr open source enterprise search platform web application. This tutorial describes the steps for launching this environment in the cloud.
The methods to secure access to your application server depend on your cloud provider. For Amazon EC2, CloudStack, and other clouds that support security groups, you must have a security group defined with TCP port 22 open for SSH access, the default application port (8000) open to applicable load balancer servers, and any other port and protocol access required by your application.
Iptables is enabled by default on all servers, with the default SSH port (22) and web-access ports (80 and 443) open. In addition, the application communications port, TCP port 8000, is automatically open on each application server to all HAProxy load balancer servers in the deployment that relate to the Load Balancer with HAProxy ServerTemplate.
If you need to open other ports on an application server besides the defaults (22, 80, 443, and 8000), you must create the appropriate rules using the "Firewall" inputs, as described in the Base ServerTemplate for Linux (Chef) documentation. For more information on iptables, refer to the Linux supporting documentation for this tool.
Follow these steps to add an application server to the deployment:
The next step is to define the properties of your application server by entering values for inputs. It is simplest to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.
To enter inputs for the Chef recipes that run on your application servers, open the deployment's Inputs tab and click Edit, then follow the directions below to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.
|Input Name||Description||Example Value|
|Backup Primary Secret||Choose a cloud to store backups and provide your cloud authentication credentials. For Rackspace Cloud Files, use your Rackspace account API key (e.g., cred:RACKSPACE_AUTH_KEY). For clouds that do not require primary credentials (e.g., Amazon), set to 'ignore'.||e.g. cred:CLOUDPROVIDER_AUTH_KEY|
|Backup Primary User||Choose a cloud to store backups and provide your cloud authentication credentials. For Rackspace Cloud Files, use your Rackspace login username (e.g., cred:RACKSPACE_USERNAME). For clouds that do not require primary credentials (e.g., Amazon), set to 'ignore'.||e.g. cred:CLOUDPROVIDER_USERNAME|
|Solr Master DNS ID||The unique identifier that is associated with the DNS A record of the master server. The unique identifier is assigned by the DNS provider when you create a dynamic DNS A record. This ID is used to update the associated A record with the private IP address of the master server when this recipe runs.||e.g. text:1234567|
|Backup Lineage for Solr|| |
The name associated with your primary and secondary database backups. It's used to associate them with your database environment for maintenance, restore, and replication purposes. Backup snapshots will automatically be tagged with this value. Backups are identified by their lineage name.
Note: For servers running on Rackspace, this value also indicates the Cloud Files container to use for storing primary backups. If a Cloud Files container with this name does not already exist, one will automatically be created.
|Solr Master Host||Your hostname of the Solr Master server.||e.g. text:solr-example.com|
|DNS Service Provider||The name of your DNS provider. Select the DNS provider that you're using to manage the DNS A records of your master/slave database servers (e.g., DNSMadeEasy, DynDNS, Route53).||select a DNS provider from the drop-down|
|DNS Password||The password that is used to access and modify your DNS A Records. For DNS Made Easy and DynDNS, enter your password (e.g., cred:DNS_PASSWORD). For Amazon Route53, enter your AWS secret access key (e.g., cred:AWS_SECRET_ACCESS_KEY)||cred:DNS_PASSWORD|
|DNS User||The user name that is used to access and modify your DNS A records. For DNS Made Easy and DynDNS, enter your user name (e.g., cred:DNS_USER). For Amazon Route53, enter your Amazon access key ID (e.g., cred:AWS_ACCESS_KEY_ID)||cred:DNS_USER|
Go the Servers tab of your deployment and click the launch button to launch your server.
To test your server, go to the Servers tab of your deployment and click on your operational Solr server's nickname. In the Info tab, click the Public DNS name. You should see the Solr redirect page which will redirect you to the Solr Welcome page:
Note: if the Solr welcome page does not appear, check /var/log/tomcat6/catilina.out to ensure Tomcat is running.
For a master/slave configuration, you need to create another server.
|Input Name||Description||Example Value|
|Solr Server Type (Master, Slave)||Specify the server type (master or slave) for the Solr server.||text:slave|
Re-run the solr::replication under Boot Scripts on the slave's Scripts tab. After the recipe completes, the slave becomes the new master.
Note: if replication is not working, check the replication page on both servers, ping the hostname to make sure it resolves properly. Also check your security group to make sure port 8000 is open.
The Solr Tomcat App Server stores backups on an ephemeral drive, which means these backups only persist throughout the life of the server and will be lost on termination. An alternative for storing backups is using volumes. To backup to a volume, in the deployment view click on the Scripts tab of your running server for the following actions:
© 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.