I am fairly new to TokuDB but so far I am impressed with the compression it provides to the data stored within. One of my clients has a ton of data that is constantly growing and thus TokuDB made a lot of sense for the solution that was created. While becoming more familiar with TokuDB and trying different cloud solutions I ran into a minor issue installing TokuDB on a Google Cloud VM instance but explain how to resolve easily below.
I typically use Amazon’s AWS EC2 cloud services which include Route53 for DNS however I have certain clients that prefer RackSpace and therefore require RackSpace Cloud DNS services. One of the primary reasons for not just using an external DNS service such as Amazon’s Route53 DNS service is because when you setup large cloud deployments you typically are going to need internal DNS entries for communication between cloud instances and DNS services such as Route53 will not respond externally to RFC1918 or private IP space for those DNS entries. Anyhow one thing that is well documented or easy to accomplish on Route53 is creating A records with multiple IP’s for round robin DNS which provides a cheap easy to configure load balancing of sorts for different services such as MySQL. I could not find any documentation or mention of round robin DNS setup on RackSpace Cloud DNS so I wanted to explain how I was able to accomplish this.
If you have created a custom RightScript in the RightScale interface that uses git to clone a repository and you are running that RightScript on boot following the RightScale git_repo recipe then you likely are having issues. The problem appears to stem from the fact that the environment variables are not completely cleaned up as expected including $GIT_SSH and possibly others. I have a work around noted below along with a line you can enter in your RightScript to clear the $GIT_SSH ENV variable as well.
Having trouble logging into an AWS instance using an SSH key? I was too and when I finally figured out what the issue was I was kicking myself. Recently I was called to assist figuring out information about a clients AWS deployment for a project where the original developers were no longer available or answering questions. Most of the instances that I initially worked on had no issues once I was able to obtain the correct SSH key pem file from Amazon. When the project was closing down I was asked to assist backing things up and it appeared the SSH key was failing for two of the instances which also happened to be the oldest two instances (2 years old). Below I describe the error I was seeing via SSH as well as the easy resolution to the problem.
The below code snippet was used to add SSH users to RackSpace cloud CentOS Linux nodes being used as application servers and managed via RightScale. The SSH users were required during a testing phase so they could look through logs and make modifications to specific configuration files, etc. There are three things that have to happen to create the SSH user, allow them to login, and provide them the necessary rights on the server to accomplish their tasks which include adding the user, modifying the sshd config to allow password logins, and update the sudoers file to enable sudo access for wheel group users.