Veeam Cloud Backup and OpenStack - Configuration

[JulianL]

I've got a local demo of DevStack running that I am trying to point my copy of Veeam Backup Cloud Edition to. I have generated the API key, but it's bigger than expected - however there was no error at that point. I have also assumed that the 'authentication service' in the Veeam dialogue box is the IP and port of the web service (http://<ip_address>:5000).

I get an unusual error when I try to specify the container, but I can't tell what's wrong. Any ideas? I assume this is debug output?

Error:


I'm using the Folsom DevStack on Ubuntu 12.10.

[foggy]

Julian, please include the support case ID if you'd like to keep this topic open. With all technical issues, opening a case should be the first step, as it is explained when you click New Topic.

[tsightler]

Is Swift storage configured and enabled on your DevStack instance and has the user with the associated API key been assigned to a storage volume? Also, you may need to disabled SSL on the advanced options if you have not enabled SSL on the DevStack instance (I don't know if this is automatic as part of the DevStack install, but your URIs are non-SSL). I had to do this with my development Walrus (S3 compatible) storage as well.

[JulianL]

Thanks Tom, I'll check that out.

[tsightler]

So I had a few minutes to mess around with DevStack and it doesn't take much to get it to work with CE. For one thing, CE requires the SWIFT object storage service to be enabled in OpenStack, which it is not by default in DevStack. This is simple enough to enabled during DevStack deployment, just edit the "localrc" file and add the line "enable_service swift" to it prior to running "stack.sh". You might want to override the default location and size of the swift devices using the SWIFT_DATA_DIR or SWIFT_LOOPBACK_DISK_SIZE as well. Once DevStack is deployed you can verify that SWIFT is enabled by logging into the OpenStack portal and accessing any project. You will see "Object Store" and "Containers" if SWIFT is properly deployed. You can create a container at this point, but you can also create them from the CE UI during account setup.

It appears to me that DevStack is deployed by default with Keystone authentication enabled, which is no big deal, but requires the proper configuration to enable CE to authenticate. Basically, Keystone authenticates to the service using the username/password and acquires a 24-hour token for all further communications with the API so, to make this work with CE, the Auth URL must be set to "http:<ip_or_name_of_server>:5000/v2.0/tokens". Notice the addtion of "tokens" on the end of the URI you had previously attempting to use. Now, in the "API Key" field you will enter, not an API Key at all (confusing right), but actually just the password for the user to access OpenStack. Also, you will need to enable the "Keystone authentication" option, and enter the tenant name or ID. For my simple home setup I used the admin user, and the admin tenant, but it's pretty easy to determine the tenant username or password by looking at URLs displayed on the "API Access" (the UUID on the end of the various URLs listed), or on the "Projects" tab from the admin menu.

With these few tweaks I was able to add my new DevStack based OpenStack storage instance to CE, create a container, and backup and restore files. I'm not sure that DevStack would be a great choice for such a solution as it doesn't seem very "persistent" (I'm not even sure how to "restart" it after a reboot) but it is very easy to deploy. Total time to install Ubuntu server 12.04.2 LTS, and DevStack was about 30 minutes, perhaps less.

[dkvello]

Did You use this Coockbook when installing the Object Store ?
http://docs.openstack.org/trunk/opensta ... orage.html

I haven't fully understood If you have to have a complete OpenStack implementation, or if You can just do like the URL above says. one Proxy and a couple of Storage nodes.

[tsightler]

That's not what I used, and I'm certainly no OpenStack expert at this point but I'm pretty sure you have to have at least the core stack running since this is still used for administration and authentication.

So far I deployed the "DevStack" implementation above using the instructions at http://devstack.org/guides/single-vm.html

I've also performed a more "complete" OpenStack development environment on RHEL 6.3 using the EPEL repositories and following these instructions:
http://fedoraproject.org/wiki/Getting_s ... Stack_EPEL

Both of these worked fine with CE and were trivial to install but I much preferred the full OpenStack EPEL development because it is persistent. You can reboot the server and it will come right back up with all accounts and fully functioning services.

One thing I have noticed is that, once you start using the SWIFT storage, the server will use a lot of I/O performing background integrity checks continuously, which seems like overkill for a simple development setup. It's probably worse since it's a "cloud-in-a-box" setup with all nodes running on a single VM. I understand that you can throttle this background I/O by tweaking a few parameters.