For the purposes of this discussion, we will refer to "the cloud" as Amazon's EC2 environment since that is by far the most common cloud-based environment. However, the same considerations apply to any environment that acts like EC2 (an organization's private cloud for example). In terms of the software itself, we have done extensive testing within EC2 (and some of our largest customers have already deployed Membase there for production use). Because of this, we have encountered and resolved a variety of bugs only exposed by the sometimes unpredictable characteristics of this environment.
Being simply a software package, Membase Server is extremely easy to deploy in the cloud. From the software's perspective, there is really no difference being installed on bare-metal or virtualized operating systems. On the other hand, the management and deployment characteristics of the cloud warrant a separate discussion on the best ways to use Membase.
We have written a number of RightScale templates to aid in your deployment within Amazon. You can very easily sign up for a free RightScale account to try it out. The templates handle almost all of the special configuration needed to make your experience within EC2 successful. Direct integration with RightScale also allows us to do some pretty cool things around auto-scaling and pre-packaged deployment. Check out the templates here: Membase on RightScale .
We've also authored an AMI for use within EC2 independent of RightScale. When using these, you will have to handle the specific complexities yourself. You can find this AMI by searching for 'membase' in Amazon's EC2 portal.
Some considerations to take into account when deploying within the cloud are:
Local storage being ephemeral (requiring special attention for backups)
IP addresses of a server changing from runtime to runtime
Security groups/firewall settings
swap
Local Storage
Dealing with the first point is not very much different than a data center deployment. However, EC2 provides an interesting solution. Through the use of EBS storage, you can obviate the largest concern of losing your data when an instance fails. Writing Membase data and configuration to EBS creates a reliable medium of storage. There is direct support for using EBS within RightScale and of course you can set it up manually yourself.
Using EBS is definitely not required, but you should make sure to follow the best practices around performing backups.
Keep in mind that you will have to update the per-node disk path when configuring Membase to point to wherever you have mounted an external volume.
IP addresses
The second issue is a bit trickier and requires configuring Membase to use a DNS entry instead of an IP address. By default, Membase servers use their IP address as a unique identifier. If the IP changes, an individual node will not be able to identify its own configuration and other nodes that it was clustered to will not be able to access it. In order for a node to identify itself via a DNS name rather than and IP address, the following instructions must be followed. Note that this configuration is automatically handled by the RightScale server template.
A few points to keep in mind when setting this up:
Make sure that this hostname always resolves to the IP address of the node that it is on. This can be accomplished by using a dynamic DNS service such as DNSMadeEasy which will allow you to automatically update the hostname when an underlying IP address changes.
It is best to make sure that the IP address registered with the hostname is the internal address for the node (rather than the external one provided by Amazon) so that other nodes and application machines can contact it
The below steps will completely wipe any data and configuration from the node, so it is best to start with a fresh Membase install. If you already have a running cluster, you can easily rebalance a node out of the cluster, make the change and then rebalance it back into the cluster. Nodes with IP's and hostnames can exist in the same cluster.
For Linux:
Install the Membase software
Execute: 'sudo /etc/init.d/membase-server stop'
Edit the script located at /opt/membase/bin/membase-server (Pre 1.7 path is: /opt/membase/<version>/bin/membase):
Add a '\' to the end of the last line
Add a new last line that reads: "-name ns_1@<hostname>" (without the double quotes) where <hostname> is either a DNS name or an IP address that you want this server to listen on (the 'ns_1@' prefix is mandatory):
...rest of file... -detached \ -run ns_bootstrap -- \ -ns_server config_path "\"/opt/membase/etc/membase/static_config\"" \ -name ns_1@membase1.company.com1. Delete the files under:
/opt/membase/var/lib/membase/data/* (Pre 1.7 path is:/var/opt/membase/<version>/data/ns_1/)
/opt/membase/var/lib/membase/mnesia/* (Pre 1.7 path is:/var/opt/membase/<version>/mnesia/)
/opt/membase/var/lib/membase/config/config.dat (Pre 1.7 path is:/etc/opt/membase/<version>/ns_1/)
Execute: 'sudo /etc/init.d/membase-server start'
See the node correctly identifying itself as the hostname in the GUI under the Manage Servers page (you will be taken back to the setup wizard since the configuration was cleared out, but after completing the wizard the node will be named properly).
For Windows:
Install the Membase software
Stop the service by running C:\Program Files\Membase\Server\bin\service_stop.bat
Unregister the service by running C:\Program Files\Membase\Server\bin\service_unregister.bat
Edit the script located at C:\Program Files\Membase\Server\bin\service_register.bat:
On the 7th line it says: set NS_NAME=ns_1@%IP_ADDR%
Replace "%IP_ADDR%" with the hostname/IP address that you want to use
Register the service by running the modified script: C:\Program Files\Membase\Server\bin\service_register.bat
Delete the files located under: C:\Program Files\Membase \Server\var\lib\membase\mnesia
Start the service by running C:\Program Files\Membase\Server\bin\service_start.bat
See the node correctly identifying itself as the hostname in the GUI under the Manage Servers page (you will be taken back to the setup wizard since the configuration was cleared out, but after completing the wizard the node will be named properly).
Security groups/firewall settings
It's important to make sure you have both allowed AND restricted access to the appropriate ports in a Membase deployment. Nodes must be able to talk to one another on various ports and it is important to restrict external and/or internal access to only those individuals you want to have access. Unlike a typical data center deployment, cloud systems are open to the world by default and steps must be taken to restrict access.
swap
Certain cloud systems by default don't have a swap partition configured. While a system should not utilize a swap partition heavily, it is our recommended practice to have at least some amount of swap configured to avoid the kernel from killing processes.