10

Playing with the new Veeam SOSAPI for Object Storage

 1 year ago
source link: https://www.virtualtothecore.com/playing-with-the-new-veeam-sosapi-for-object-storage/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Playing with the new Veeam SOSAPI for Object Storage

Twitter 0 Tweet Facebook 0 LinkedIn 0 Email -- Email to a friend 0 Flares
In my previous article I introduced the new Veeam SOSAPI. In this following post, I will show you a bit more how it works under the hood.

Using the filesytem as an the SOSAPI endpoint

Veeam took an interesting and uncommon approach to a very specific problem: how do you trasparently add a new set of API calls to an existing API protocol like AWS S3? As much as purist programmers would probably not like this, in my opinion Veeam developers found a very clever solution. The SOSAPI calls are made by the Veeam VBR server (or any potential supported Veeam product in the future) by reading a series of xml files that are stored in the S3 bucket where the api themselves are enabled. The information in the xml files defines the answers to the calls, while from the S3 point of view, that’s just a read operation against a file.
Folders and files have to be precisely crafted in order to be consumed by a SOSAPI source. First, a specific folder has to exist in the root of a given S3 bucket:
Pasted-6.png?resize=640%2C85&ssl=1
Inside the folder, two files are created and updated by the storage system itself:
Pasted-7.png?resize=640%2C87&ssl=1
Veeam SOSAPI uses two files, system.xml and capacity.xml, under the <bucket>/.system-d26a9498-cb7c-4a87-a44a-8ae204f5ba6c/ folder in each S3 Bucket.
Look at the date in the column “Modified on”. system.xml defines a set of environment configuration for the S3 Bucket, and can be used to enable or disable SOSAPI on a specific S3 Bucket. This is its content:
<?xml version="1.0" encoding="UTF-8" ?>
<SystemInfo>
<ProtocolVersion>"1.0"</ProtocolVersion>
<ModelName>"ARTESCA v1.7"</ModelName>
<ProtocolCapabilities>
<CapacityInfo>true</CapacityInfo>
<UploadSessions>false</UploadSessions>
<IAMSTS>false</IAMSTS>
</ProtocolCapabilities>
</SystemInfo>
<?xml version="1.0" encoding="UTF-8" ?>
<SystemInfo>
<ProtocolVersion>"1.0"</ProtocolVersion>
<ModelName>"ARTESCA v1.7"</ModelName>
<ProtocolCapabilities>
<CapacityInfo>true</CapacityInfo>
<UploadSessions>false</UploadSessions>
<IAMSTS>false</IAMSTS>
</ProtocolCapabilities>
</SystemInfo>

Here the storage is declaring to the Veeam Backup Server its capabilities, and who it is. In my lab I’m using a Scality Artesca VM, and the bucket is enabled to expose the Capacity information. The final result inside Veeam console is this:

Pasted-8.png?resize=640%2C50&ssl=1

The volume doesn’t show the usual “unlimited” capacity of a typical S3 bucket, but it shows the total capacity and the free space. Obviously, the capacity may not be the overall capacity of the storage system, it can also be a quota that the storage admin has decided to assign to that bucket. This is very useful for backup services, for example when Veeam Backup Server has to choose which extent of a SOBR to use, or in a multi-tenant environment, where the Veeam admin wants to limit the storage consumption of each tenant accessing the system, by assigning specific buckets to each customer.
But where does the capacity values come from? The metric is written in the file capacity.xml, constantly updated by the storage system; that’s why the modified date of the file is always up to date. Veeam then reads this file every 4 minutes and updates its own statistics.
<?xml version="1.0" encoding="UTF-8" ?>
<CapacityInfo>
<Capacity>100000000000</Capacity>
<Available>99484498874</Available>
<Used>515501126</Used>
</CapacityInfo>
<?xml version="1.0" encoding="UTF-8" ?>
<CapacityInfo>
<Capacity>100000000000</Capacity>
<Available>99484498874</Available>
<Used>515501126</Used>
</CapacityInfo>

All the values are expressed in bytes and dynamically computed by the storage system.

This entry was posted in Tech and tagged API, capacity, s3, sosapi, veeam, XML. |


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK