Nirvanix SDN delivers speed, flexibility

Nirvanix's SDN was both highly flexible, and comparatively fast in our testing. Nirvanix allows access to the SDN via two methods, an API that supports SOAP or REST protocols over secure-HTTP, or one can directly mount partition(s) using their CloudNAS as a gateway.

There's an installation program on certain supported Linux machines — physical or virtual; we used Ubuntu 9.0.4 Linux, but didn't use the Windows CloudNAS software.

For a one-node storage delivery network, Nirvanix charges 25 cents per gigabyte of storage per month, 10 cents per gigabyte for uploads and 15 cents per gigabyte for downloads, and 20 cents per 1000 calls for requests.

We had to create the virtual machine by ourselves and install all prerequisites and then install CloudNAS supplied in a zip file for various distributions of Linux (an .exe file installs CloudNAS for Windows).

CloudNAS is mounted directly into the Linux filesystem. It's possible to use the CloudNAS system to encrypt (using AES 256-bit) but it's not convenient. We could find no documentation regarding the creation of encryption keys, only where to store them. We had to create the keys by ourselves and set them in a config file, then CloudNAS used them to automatically encrypt and decrypt while uploading/downloading the files to/from the cache.

Cache can only be enabled if you have a minimum of 200GB free space. If cache is not enabled (an option), then encryption can't be used. The Nirvanix SDN can be accessed via Ruby, Java, JavaScript, .Net/C#, Adobe AIR, PHP, Perl, Python, and more.

Nirvanix had support for the largest file size, 256GB, which can be sent using HTTP upload, or the upload functions of SOAP or Ruby. Nirvanix has an overall size limitation of 2TB stored, but more is available under contract, says Nirvanix.

Nirvanix also has the capacity to configure default storage security via AES, separate from the SSL connection from the CloudNAS to the SDN. Key strength increments range from 128 through 256-bit AES. When accessing files using the Nirvanix API or Web services, we could create child accounts for each application and those could be used to login and retrieve files.

Nirvanix calls their data stores "applications" so that you can use a different store (and therefore different hierarchy) for each application and they would be separated. We had one "application" for CloudNAS and one "application" for testing the API. They were completely separate, although it’s possible to just use one for everything.

Nirvanix straddles the line between API-connected file containerization, and the NAS world, where the actual drive is in the cloud.

Return to main test.

Join the discussion
Be the first to comment on this article. Our Commenting Policies