Today I’m going to talk about configuring DNS and HTTPS for WordPress on S3. DNS stands for Domain Name System and it is the technology that makes it possible to use friendly names for web sites. HTTPS stands for Hypertext Transfer Protocol Secure and it is the technology that makes secure connections possible.

DNS

When you first launch the website, its name is going to look like something like this: http://ec2-204-236-192-217.compute-1.amazonaws.com. The name is just a representation of the website IP address, which is an ephemeral IP address.  Ephemeral IP addresses are random and change every time the instance stops and starts.

So how do you get from a random name to a nice descriptive name for your website?  There are three components to it:

1. You need to register your domain name with a domain name registrar.  The domain name registrar is going to make sure that the name is not registered to someone else and register it to you for a certain period of time.
2. You need to choose a DNS hosting service.  Domain name registrars usually can provide DNS hosting service, or you can use Amazon Route 53 DNS web service.  Once you’ve picked the DNS hosting service provider, you need to inform the registrar to set the name servers for your domain to the ones associated with your DNS service provider.
3. You need to associate an elastic IP address to the instance.  Unlike ephemeral IP addresses that change every time the instance stops and starts, an elastic IP address is going to stay the same as long as it’s allocated.  This blog has great step-by-step instructions on how to associate an elastic IP address with the instance.  Once you get an elastic IP address, you need to create a DNS A record pointing to the elastic IP address.

Once you’ve done this, anyone will be able to access your website by the name of your choice.

HTTPS

If you have a website that handles sensitive data (e.g. personal data) you need to provide secure access to your website over the HTTPS protocol.  Once an HTTPS connection is established, all communication between the web browser and your website is encrypted.  But how does the web browser know that it’s talking to your website and not some malicious website set up by a hacker?

To confirm the identity of your website, you need to obtain an SSL certificate for your domain name and set it up on the server.  There are multiple certificate authorities that can issue a certificate.  To get a certificate, you need to generate a certificate signing request (CSR) and send it to the certificate authority of your choice.

You can generate CSR using the openssl command line utility.  If you’re not comfortable with command line, here is a nice web UI that can help you to generate the correct command line based on your input. You can then run in the Webmin console.

Here is an example of how to do this.

Go to https://www.digicert.com/easy-csr/openssl.htm and enter your information into the web form, like this:

Note that you don’t have to buy a certificate from DigiCert – the command line is the same regardless of what certificate authority that you use (including the ones that provide certificates for free).

To execute the resulting command you can use the Webmin console.  In Webmin, navigate to Others, then to Command Shell, paste the command and execute it:

As a result, the command will create two files, both located in the /root directory:

• your_domain_com.key – your private key
• your_domain_com.csr – the CSR that you need to send to the certificate authority

You should copy the private key to /etc/pki/tls/private/.  This can be done using the following command (type it in the same command shell box):

cp your_domain_com.key /etc/pki/tls/private/

Note that the private key is not known to anyone but you.  The private key is the piece of data that proves your website’s identity, so you should not share it with anyone.

You can download the CSR using Webmin.  In Webmin, navigate to Others, then to Upload and Download, then switch to the Download from server tab, enter /root/your_domain_com.csr as the File to download, and click Download:

Then you can send the CSR to your certificate authority.  Note that the CSR file is a text file, so if your certificate authority needs CSR pasted in email, you can open the CSR file in a text editor and copy its content.

It is also a good idea to download your private key so that you can have a backup copy of your private key.  If you lose your private key, you’ll have to request a new certificate.

Once the certificate authority has validated your identity they will send you a certificate file and maybe a certificate chain file.  You should upload the files into /etc/pki/tls/certs/.  In Webmin, navigate to Others, then to Upload and Download, then switch to the Upload to server tab, choose the files, type in the directory to upload to and click Upload:

Now that you have all files in place, you need to configure Apache to use the files.  In Webmin, navigate to Servers, then to Apache Webserver and click on the virtual server in the middle:

Then click on Edit Directives:

You’ll be presented with the configuration file that has the SSL configuration for the webserver.  You need to locate the following options and set it to the appropriate values:

SSLCertificateFile /etc/pki/tls/certs/your_domain_com.crt
SSLCertificateKeyFile /etc/pki/tls/private/your_domain_com.key
SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle.crt

Note that if the certificate authority didn’t give you the certificate chain file, you don’t need to set SSLCertificateChainFile.

Once you’ve modified the configuration, click Save:

Once the configuration is saved, click Apply Change link at the top right of the screen and that’s all you need to get a webserver that supports HTTPS.

Launch your website today at http://www.oblaksoft.com/downloads/, using WordPress-on-S3 AMI as the starting point.

MySQL is famous for its pluggable storage engine architecture which allows a DBA or an application developer to choose the right engine for the task. An application uses MySQL API and is isolated from all of the low-level implementation details at the storage level. As an example, the Cloud Storage Engine (ClouSE) enables existing MySQL applications to use cloud storage such as Amazon S3 or Google Cloud Storage to store its data. The application doesn’t need to be changed or even redeployed: with ClouSE, remote cloud storage will look like a better (ultra-scalable, durable, always-on) alternative to the local storage.

As you may already know, ClouSE now supports MySQL 5.6 release series.  See this announcement for more detail. Let’s go through the set of changes that were required on the ClouSE side in order to keep up with core MySQL 5.6 changes.

We had to adapt our code to compile and work with MySQL 5.6 while keeping 100% compatibility with MySQL 5.5. As much as we could, we tried to fix the code in a way that would work with both release series, but there are cases where the code has to be conditionally compiled for each release series.

Here is the list of MySQL 5.6 breaking changes and our solutions, in no particular order.

key_parts member is removed from struct st_keys

In MySQL 5.6 struct st_keys (defined in sql/structs.h) doesn’t have the key_parts member.  Now it has user_defined_key_parts, actual_key_parts and a couple other xxx_key_parts members instead.  This change is apparently related to extended secondary keys model that the optimizer in 5.6 uses to do certain query optimizations for InnoDB.

The user_defined_key_parts member corresponds to the number of index columns that are specified by the user in the CREATE TABLE, ALTER TABLE, and etc. statement.  The actual_key_parts member also includes the number of PK columns that are implicitly present in InnoDB secondary indexes (thus user_defined_key_parts <= actual_key_parts).

To adapt ClouSE handlerton code for the new structure (in a way that would work both in MySQL 5.5 and 5.6), we replaced all key_parts usage with user_defined_key_parts and added the following code at the top of the handlerton source file:

#if MYSQL_VERSION_ID < 50610
#define user_defined_key_parts key_parts
#endif

(50610 is not necessarily the precise check, but we don’t support 5.6 versions prior to 5.6.10, so it’s precise enough for our purposes).

Unfortunately, MySQL 5.6 uses a hardcoded check for InnoDB when it decides to account for PK columns in the actual_key_parts member.  So for any other engine user_defined_key_parts is equal to actual_key_parts.  Thus even though ClouSE also has PK columns in secondary indexes (a typical design for B-tree-based access methods), it has no way of engaging the extended secondary keys logic in MySQL.

What’s worse is that the extended secondary keys are now used in optimizations that previously used different logic.  Because of that, some optimizations that work in MySQL 5.5 for all engines, only work for InnoDB in MySQL 5.6.  For more details about the regression, see this bug.  We hope that the MySQL dev team is able to fix it soon.

New *TIME*2 types

MySQL 5.6 has 3 new time data types: MYSQL_TYPE_TIMESTAMP2, MYSQL_TYPE_DATETIME2, and MYSQL_TYPE_TIME2 that represent the new time data types that are capable of storing fractional seconds.  The old time data types are still present and supported for backward compatibility, however new tables are created with the new time data types.

Adding support for the new type turned out to be fairly easy.  We added code like:

#if MYSQL_VERSION_ID >= 50610
case MYSQL_TYPE_TIMESTAMP2: case MYSQL_TYPE_DATETIME2: case MYSQL_TYPE_TIME2:
#endif

to the switch statement where we map MySQL data type to ClouSE data types, and we treat the new time types as fixed-sized binary fields.

timestamp_field_type is removed from struct TABLE

In MySQL 5.6 struct TABLE (defined in sql/table.h) doesn’t have the timestamp_field_type member anymore.  TIMESTAMP_AUTO_SET_ON_INSERT, TIMESTAMP_AUTO_SET_ON_UPDATE etc. are gone as well.  This change is apparently related to improved automatic initialization and updating of TIMESTAMP and DATETIME.

Along with this change the code that handles automatic initialization and updating is apparently hoisted from storage engines to the core MySQL code, so the fix is trivial:

#if MYSQL_VERSION_ID < 50610
    if( table->timestamp_field_type & TIMESTAMP_AUTO_SET_ON_INSERT )
        table->timestamp_field->set_time();
#endif

I.e. the code is just excluded from ClouSE handlerton when it’s compiled for MySQL 5.6.

MySQL 5.6 doesn’t load field values for duplicate key error on UPDATE

Consider the following example:

mysql> CREATE TABLE t1 (
          id    INT KEY,
          first CHAR(16) NOT NULL,
          last  CHAR(16) NOT NULL,
          UNIQUE KEY (first, last)
       ) ENGINE=CLOUSE;
mysql> INSERT INTO t1 VALUES (1, 'foo', 'bar'), (2, 'abc', 'bar');
mysql> UPDATE t1 SET first='foo' WHERE id=2;

The result is a duplicate key error:

ERROR 1062 (23000): Duplicate entry 'foo-bar' for key 'first'

The UPDATE operation does not use the last field, so MySQL doesn’t read its values during normal processing.  Because of that, MySQL 5.5 has special logic that would explicitly load all field values of the duplicate key to show in the error message.

In MySQL 5.6 the logic is removed, so the error message in the example above would look like:

ERROR 1062 (23000): Duplicate entry 'foo-' for key 'first'

To fix this issue, we copied the code from MySQL 5.5 into the ClouSE handlerton.  The function that has this logic in MySQL 5.5 is prepare_record_for_error_message (located in sql/sql_update.cc).

In conclusion

Adding support for MySQL 5.6 release series while keeping compatibility with MySQL 5.5 release series turned out to be fairly straightforward.  We were able to adapt ClouSE handlerton and it works with MySQL 5.6 as well as or better than with MySQL 5.5.

If you have any questions or suggestions, please don’t hesitate to provide feedback in the comments or contact us directly.  Or just go ahead and download ClouSE or WorPress-to-Cloud (which uses ClouSE under the covers) to try it with MySQL 5.6.

OblakSoft is pleased to announce the release of Cloud Storage Engine (ClouSE) installer that can be used to deploy and configure ClouSE with your MySQL server. Now ClouSE can be deployed with just one command. The installer will guide the user through the configuration process, prompt for Cloud Storage connection parameters, and install ClouSE into MySQL.

Presented is a step-by-step guide for ClouSE installation and configuration, from downloading the binaries to running the installer. The guide was designed by request of WordPress-to-Cloud users, however it is fully applicable to any generic ClouSE installation.

The slides have notes, they are a little hard to discover with the SlideShare interface, look for a tab below the slide that looks like “Notes on Slide #”.

Let us know how we can further streamline cloud adoption for your MySQL applications.

OblakSoft is pleased to announce the release of Cloud Storage Engine (ClouSE) for MySQL Beta version 1.0b.1.7.  In this release we added support for a variety of environments to address the platform diversity of our growing customer base.

Here is the summary of changes that are included into 1.0b.1.7:

• Support for ClouSE on Microsoft Windows (limited preview)

Now ClouSE builds are available both for Linux and Microsoft Windows.  The cloud data format is the same across all platforms: Linux and Windows, 32-bit and 64-bit.  This allows for seamless transitions between machines, platforms and clouds.  ClouSE for Windows is currently available to a group of limited preview customers.  If you would like to sign up for the limited preview program please contact us.
Looking forward to your feedback, comments, questions, bug reports.

• Support for MySQL 5.6 release series

Now ClouSE supports MySQL 5.6.10 – the first GA version in MySQL 5.6 series.

• Support for latest MySQL 5.5

Now ClouSE supports MySQL 5.5 release series through 5.5.30.

• Support for Percona Server 5.5.29-rel30.0

Now ClouSE support Percona Server 5.5.29-rel30.0.  Percona Server is supported only on Linux.  The handlerton library for Percona Server is ha_clouse-5.5.29-p30.0.so.

• Support for partitioned tables

Now ClouSE supports partitioned tables.  Partition’s metadata is saved to cloud storage and transparently recovered on auto-discovery.

The software can be downloaded at http://www.oblaksoft.com/downloads/ for FREE.

For the full list of new features and bug fixes see the release notes.

Please let us know if you run into any issues trying WordPress (or directly MySQL) on cloud storage. We’ll make sure to address them as our top priority.

OblakSoft is pleased to announce availability of the ready-to-run WordPress-on-S3 / Yapixx AMI with enhanced configuration, performance, and website administration features.  Now website owners can use Webmin and phpMyAdmin for secure website administration over the Internet, and pre-configure Cloud Storage Connection for the instance.

System administration

For extra security, Webmin and phpMyAdmin are configured to use TCP ports 12321 and 12322, correspondingly.  This setup provides a simple and flexible way to secure access to system administration functionality without affecting the website operation.  Access to the system administration functionality can be easily added and removed by modifying the firewall (a.k.a. security group) settings in the AWS management console.

By default, the administration TCP ports are closed. To allow access to Webmin and phpMyAdmin, add the following rule to the security group of the instance (if you’re following the step-by-step guide, see slides 8 and 9):

You can restrict the access further by specifying the IP address range in the source field.  Note that rules can be added to and deleted from the security group at any time and take effect immediately. You can open the administration TCP ports for the time you need to make configuration changes and close the ports after you’re done.

To access Webmin, go to https://ec2-N-N-N-N.compute-X.amazonaws.com:12321 (substitute the host name with the real EC2 name).  You’ll see a warning that there is a problem with the SSL certificate.  This is expected: the certificate is generated for each instance and you can confirm the authenticity as described on the slides 13 and 14 of the step-by-step guide.

Initially, all accounts on the instance are locked, so to log into the Webmin you need to set up the root password first.  One way to do it is to connect to the instance using SSH or PuTTY and run the sudo root passwd command.  But we made it even easier. With the new WordPress-on-S3 AMI you can set the root password in the user data when creating an instance.  The syntax for root password is the following:

os.root.password=YourRootPassword

Here is a screenshot of setting the root password to SuperSecret7:

If you didn’t set the root password when you were creating the instance, you can stop the instance, edit the user data to set the root password (right click on the instance in the AWS management console and choose the “View/Change User Data” action from the menu), and start the instance again.

Please be sure to pick a strong password and keep it safe.

Once the root password is set, you can log into the Webmin and gain full access to your system.  The full Webmin documentation is available here, and some screenshots are available here.

Database administration

As mentioned earlier, phpMyAdmin uses TCP port 12322, so to access it you need to open the port and then go to https://ec2-N-N-N-N.compute-X.amazonaws.com:12322 (substitute the host name with the real EC2 name).  You’ll see a warning that there is a problem with the SSL certificate.  This is expected: the certificate is generated for each instance and you can confirm the authenticity as described on the slides 13 and 14 of the step-by-step guide.

Initially, none of MySQL accounts have passwords, which makes them inaccessible via phpMyAdmin.  So to log into phpMyAdmin, you need to set the MySQL root password first.  You do it from the command line, or you can do it in Webmin:

Note if Cloud Storage Connection is not configured, MySQL server may not be able to start, so you need to configure Cloud Storage Connection before you can administer MySQL server.

Please be sure to pick a strong password and keep it safe.

Once the MySQL root password is set, you can log into phpMyAdmin take full control over your database administration.  The full phpMyAdmin documentation is available here, and wiki pages are available here.

If you want to set password for MySQL wordpress_user, you also need to edit the wp-config.php and update the password there as well.  For quick access to wp-config.php, we added a custom command in Webmin:

Automated Cloud Storage Connection configuration

The Cloud Storage Connection Web UI (slide 12 in the step-by-step guide) is great for a quick start, but in production you might want to have the site ready from the start in an automated scripted way, without going thru manual steps.

Now you can pre-configure Cloud Storage Connection in user data when creating an instance from the ready-to-run WordPress-on-S3 AMI.  The syntax for Cloud Storage Connection configuration is the same as in the my.cnf file:

clouse_cloud_data_url=s3://s3.amazonaws.com/bucket/prefix
clouse_cloud_auth_key=AccessKey:SecretKey

You can get a name of an existing bucket or create a new bucket to store your website content in the AWS management console.  Your Access Key and Secret Key can be retrieved here.  See also slides 16 and 21 of the step-by-step guide.

Here is a screenshot of setting Cloud Storage Connection configuration (and the root password) in the user data:

If you made any mistake in the user data configuring your website instance, you can simply stop the instance, correct the user data (right click on the instance in the AWS management console and choose the “View/Change User Data” action from the menu), and start the instance again.

Performance enhancements

To help the website deal gracefully with load spikes (especially on EC2 micro instances) we added a 1 GB swap file.   Now the operating system can save rarely used data to disk and use memory to store most frequently accessed data.

To optimize PHP code execution, WordPress-on-S3 AMI now has Alternative PHP Cache (a.k.a. APC) installed and configured. To take advantage of APC even further, we configured W3 Total Cache to use APC for caching internal WordPress objects’ data and database queries.

Many of our customers use W3 Total Cache plugin to optimize their website.  The new AMI comes with W3 Total Cache pre-installed and configured for better website performance.

In conclusion

Ready-to-run WordPress-on-S3 AMI, containing up-to-date LAMP + WordPress + ClouSE + familiar admin tools and UI, allows launching a WordPress-powered website to cloud in a matter of minutes.  Now you can take full control of the website administration, all from your Web browser, no command line experience is required.  Launch your website today at http://www.oblaksoft.com/downloads/, using WordPress-on-S3 AMI as the platform.

It’ll be great to hear your thoughts on how we can further simplify the experience of launching WordPress to cloud.

The slides have notes, they are a little hard to discover with the SlideShare interface, look for a tab below the slide that looks like “Notes on Slide #”.

Hotlinking to cloud storage URLs

Hotlinking (or direct linking, inline linking) is when other sites link to or embed the image (or other media file, e.g. video) directly without providing a link to the source page. Oftentimes hotlinking happens without meaning any harm: people just want to share a picture with their Facebook friends, or post it to forums they like or etc. Regardless of intention, though, hotlinking may be harmful to your business: the media file gets downloaded from your site and consume the bandwidth that you pay for, but the user doesn’t get to see your page depriving you of ad revenue, etc.

With WordPress-to-Cloud solution all media files are stored in the cloud storage such as Amazon S3. Now it is the cloud storage (and not your web server) that serves the images and other media files. Even though this approach reduces load on your web server and hotlinking is unlikely to cause scalability problems, you are still paying for the bandwidth.

Configure access policies to cloud storage URLs

As the WordPress on S3 solution becomes more popular, we often get questions about access control to the site’s images and other media files that are stored and served by Amazon S3.

Amazon S3 supports bucket policies that can be used to implement flexible access restrictions for the objects stored in the bucket.  The access can be restricted based on various factors, including the referer header of the HTTP request that the web browser sends when it downloads the image.  I.e. if the image is downloaded from a web page, the referrer is going to be the URL of the web page.  So when the image is downloaded from your website the referrer URL is going to contain your website’s host name; but when the image is downloaded from somewhere else (e.g. Facebook) the referrer URL is going to contain some other host name (e.g. www.facebook.com).

Here is an example of a bucket policy that only allows downloading the media files if they are referred from www.example.com and www.subdomain.example.com:

{
	"Version": "2008-10-17",
	"Id": "HTTP referrer policy",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Deny",
			"Principal": {
				"AWS": "*"
			},
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::mybucket/myprefix/wblob/*",
			"Condition": {
				"StringNotLike": {
					"aws:Referer": [
						"http://www.example.com/*",
						"http://www.subdomain.example.com/*"
					]
				}
			}
		}
	]
}

The policy is specified in JSON format, but largely can be copied from the sample policy substituting the essential parts that are highlighted in red: the bucket name and the (optional) prefix, and the list of the referrer patterns.

Step-by-step instructions

Let’s launch a ready-to-run WordPress-on-S3 and do a practical study of hotlinking prevention. After following this step-by-step guide the website is going to end up looking like this:

Now suppose you like the bottom-left picture with the pool.  You copy the link and send an email to you friend.  The email is going to look like this:

Without the bucket policy in place, clicking on the link is going to do what you expect: the web browser is going to download the picture of the pool and show it.  So the link can be used anywhere: in a blog, on Facebook, on Twitter, etc.

Now let’s create a bucket policy that would only allow using the image from the website.  To do that log into the AWS management console, pick the bucket that stores the data for the website (in our example it’s oblaksoft-yapixx), choose permissions and select ‘Add bucket policy’:

Enter the following policy:

{
	"Version": "2008-10-17",
	"Id": "HTTP referrer policy",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Deny",
			"Principal": {
				"AWS": "*"
			},
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::oblaksoft-yapixx/db0/wblob/*",
			"Condition": {
				"StringNotLike": {
					"aws:Referer": "http://www.yapixx.com/*"
				}
			}
		}
	]
}

The highlighted parts correspond to this web site’s data location (oblaksoft-yapixx/db0) and the domain name of this site (www.yapixx.com). You will need to supply the values that correspond to your own setup.  Now the images still appear fine when they are embedded or referred from www.yapixx.com. But downloading the images from any other domain is going to result into the 403/Forbidden response, like this:

You can specify multiple referrers, if you wish.  For example, if you have multiple domains that are used as aliases for your web site, you can list all of them there.  You can even specify domain names that you don’t own.  For example, if you want to allow the image to be referred from web email clients, but not from social networks, you can add a policy like this:

{
	"Version": "2008-10-17",
	"Id": "HTTP referrer policy",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Deny",
			"Principal": {
				"AWS": "*"
			},
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::oblaksoft-yapixx/db0/wblob/*",
			"Condition": {
				"StringNotLike": {
					"aws:Referer": [
						"http://mail.google.com/*",
						"http://*.mail.yahoo.com/*",
						"http://www.yapixx.com/*"
					]
				}
			}
		}
	]
}

This policy allows the images to be referred from www.yapixx.com, Gmail and Yahoo! mail.

Sometimes you may want to allow requests that don’t have the referrer specified.  This can happen if you paste the image URL directly into the address field of the web browser – it’s not referred from anywhere.  In that case you can use a special Null condition for the referrer key, for example:

{
	"Version": "2008-10-17",
	"Id": "HTTP referrer policy",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Deny",
			"Principal": {
				"AWS": "*"
			},
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::oblaksoft-yapixx/db0/wblob/*",
			"Condition": {
				"StringNotLike": {
					"aws:Referer": "http://www.yapixx.com/*"
				},
				"Null": {
					"aws:Referer": false
				}
			}
		}
	]
}

So, as you can see, Amazon S3 puts you in control of where your media files can be referred from.  As of the time of this writing, Google Cloud Storage doesn’t seem to have an equivalent access control mechanism, but we hope that they will implement this functionality soon.

Looking forward to hearing your thoughts on your direct linking prevention needs and practices.

OblakSoft is pleased to announce the release of ClouSE version 1.0b.1.6.  In this release we fixed some of the known ClouSE Beta limitations as well as performance and functional bugs reported by our users.

Here is the summary of changes that are included into 1.0b.1.6:

• Support for latest MySQL 5.5

Now ClouSE supports MySQL thru 5.5.29.  To keep the distribution small, we don’t build binaries for MySQL prior to 5.5.19 anymore.  If you need one, please contact us.

• DECIMAL keys support

Now ClouSE supports using DECIMAL fields in keys.  Previously neither the primary key nor indices could include DECIMAL fields.  This fixes the following Beta limitation: DECIMAL fields cannot be used in keys.

• Tables without primary key

Now ClouSE supports tables without primary key.  Previously each table had to have a primary key.  This fixes the following Beta limitation: The table must have a primary key.

• BLOB fields support

Now ClouSE supports BLOB fields that can store more than 128 KB of data.  Previously BLOB fields were stored in the record and were limited by the maximum record side; an attempt to store a value that is larger than 128 KB would lead to an error.  This fixes the following Beta limitation: BLOB fields are stored in the record thus are limited by the max record size (128 KB).

The software can be downloaded at http://www.oblaksoft.com/downloads/ for FREE.

The release notes are available here.

If there is anything that might be blocking your deployments of ClouSE, please let us know.

OblakSoft is pleased to announce that the Cloud Storage Engine for MySQL (ClouSE) now supports Google Cloud Storage.  Using MySQL to store data directly in Google Cloud Storage becomes a simple deployment choice: pick your Google Cloud Storage bucket and migrate any or all of your tables to the cloud.  We would like to thank Google storage team for their support and contributions.

This functionality opens Google Cloud Storage to millions of MySQL-based applications – cloud storage becomes a better alternative to local storage, no matter where you host the application, on premise or in the cloud.  Applications can now store data on Google’s infrastructure, and enjoy high availability, high durability and high scalability of Google Cloud Storage.

The choice is yours

The choice of cloud storage is completely transparent to MySQL.  SQL developers and MySQL-based applications can continue using MySQL’s programing model and APIs while offloading storage management to a cloud storage provider.  Today ClouSE supports public cloud storage from Amazon and Google as well as the corresponding private cloud solutions.  All MySQL functionality as well as advanced cloud-only features such as Weblobs will work identically on either cloud.

Connecting your database to Google Cloud Storage only takes a few minutes.   Specify the cloud storage location in the /etc/my.cnf file and select a set of tables to get migrated to the cloud.

Now let’s talk about the powerful choice of deployment options for your application:

• Hybrid cloud storage integration

The application can stay on premise (or at the web hoster site) but all its data will be stored encrypted at the cloud storage of your choice.  ClouSE technology combines the best of private and public storage by delivering performance and security of local storage, plus all the benefits of public cloud storage.

• Cloud deployment

You can also both host your application and store its data in the same cloud utilizing compute services as well as storage service as utility.  E.g. our FREE ready-to-run WordPress for Google Cloud image is configured to run in Google Compute Engine  and store data at Google Cloud Storage.

• Inter-cloud deployment

You don’t even have to choose just one cloud.  The storage configuration allows to mix and match clouds.  For example, our popular WordPress-on-S3 AMI can run in Amazon EC2 and store data in Google Cloud Storage.  And vice versa: the instance can run in Google Compute Engine and store its data in Amazon S3.  This allows for gradual migration between clouds, should another cloud become more attractive down the road.

Seamless support for multiple cloud providers puts customers in control.  You can choose the configuration that works best for you to fit your requirements to enforce data confidentiality, optimize for performance, minimize cost, address regulatory requirements, take advantage of other cloud services, etc.  And you can change it when your requirements change.  There is no necessity to commit to the “One True Cloud Platform”.  With ClouSE, you can avoid vendor lock-in and make sure that your way to the cloud happens your way.

WebStor support for Google Cloud Storage

As users of open source software, we’re always delighted to contribute back.  WebStor, the high performance cloud storage access library, now can work with Google Cloud Storage too.  WebStor source code is available under the Apache 2.0 license absolutely FREE from http://www.oblaksoft.com/downloads.

WordPress launches into Google’s cloud

To take further advantage of Google Cloud, we’ve assembled a ready-to-run WordPress for Google Compute Engine [1].  Launching a highly-available dynamic website powered by WordPress into Google’s cloud can now be done with one command, like this:

gce-yapixx <instanceName> –storage_url=gs://<bucket>/<folder> –storage_auth=<secret>:<access>

Google Compute Engine takes care of making the website instance highly available.  The WordPress instance is completely stateless, as all the data stored in Google Cloud Storage.  The Google Compute Engine can just launch a new virtual machine with the same image, should the old virtual machine fail for any reason.  The cloud storage configuration is passed via the custom metadata to the instance, so at startup the new virtual machine will knowhow to access its data in Google Cloud Storage.

WordPress is one example of a MySQL-based application, which now can be configured to run in the Google cloud and take full advantage of the cloud services:

• It relies on Google Compute Engine to keep the instance highly available
• It relies on Google Cloud Storage to keep the data highly available and highly durable
• It relies on Google Cloud Storage to serve media files (such as pictures) in a highly scalable fashion
• It relies on Google Cloud Storage to distribute media files across the globe for fast access in a CDN-like manner
• Storage cost scales with usage, no upfront reservation is needed
• Storage consumption scales up and down with the amount of data stored
• No backup and recovery is needed for the website data

Launch your site to the cloud

Download our ready-to-run WordPress on Google Cloud.  Or just download the new Beta version of ClouSE to migrate your own MySQL-based application to Google Cloud Storage today.  It’s easy and FREE, no writing code is required.  The choice is yours, the software is at http://www.oblaksoft.com/downloads/.

OblakSoft is pleased to announce the release of ClouSE version 1.0b.1.4.  In this release we fixed some of the known ClouSE Beta limitations that required workarounds in some configurations.

In particular, now the popular BuddyPress WordPress plugin can store its tables in ClouSE without a patch that worked around the missing features.  If you’re using the patched version of BuddyPress 1.6.1 provided by us, you can now upgrade ClouSE and use the original BuddyPress sources.  Thank you for your patience and commitment!

Here is the summary of changes:

• Support for latest MySQL 5.5

Now ClouSE supports MySQL thru 5.5.28.  To keep the distribution small, we don’t build binaries for MySQL prior to 5.5.17 anymore.  If you need one, please contact us.

• NULL support

Now ClouSE supports NULL in all field types.  Previously, only CHAR, VARCHAR and BLOB fields could support NULL.  This fixes the following Beta limitation: Integer, date / time, decimal, float, bit, enum, and set fields must be declared NOT NULL.

• TRUNCATE support

Now ClouSE supports the TRUNCATE statement.

The software can be downloaded at http://www.oblaksoft.com/downloads/ for FREE.

The release notes are available here.

Please let us know if you run into any issues trying WordPress (or directly MySQL) on S3. We’ll make sure to address them as our 1st priority.