Love them, hate them, boycott them, hyperscalers exist and so are growing in popularity still. The introduction of hyperscale storage solutions has generated a complete new selection of possibilities to the general public, with hardly any entry cost, making them very attractive to organizations of most sizes naturally.

Today we’re likely to explore the big three (Microsoft Azure, Amazon Web Services and Google Cloud Platform), how their pricing models are differ and similar, and steps to make probably the most of them when making a backup strategy that incorporates some of them. These three aren’t the only real object storage providers that Veeam integrate with, & most of the lessons in this blog will be applicable to any storage vendor.

This is a three-part series where we review what things to be familiar with with cloud storage, how exactly to utilise this within Veeam and compare benchmarks of real scenarios effectively.

Choosing a cloud provider

When deciding which cloud fits you, there could be some organizational preferences or requirements, such as: Are you experiencing an employee with public cloud training or experience? Does a specific cloud have a preferred data region or meet a particular regulatory requirement? Once you’ve got a shortlist of cloud providers you’re permitted to use, it’s time and energy to review their costs.

Filtering through all of the options

If you believe that selecting a cloud provider was the hard part, wait just! Cloud providers offer different pricing options such as for example storage costs and tiers for data writes and retrievals. It could be very tempting to check out the cheapest just, but all isn’t since it first seems always. Let’s jump in!

What’s a storage tier?

A storage tier is really a assortment of cloud resources made to meet specific use cases predicated on generic customer needs. For instance, Microsoft Azure’s “Hot” tier, Amazon Web Services’ “S3 Standard” tier and Google Cloud Platform’s “Standard” tier are believed “hot” tiers of storage. They are classed as “hot” because they’re created for frequent data access. As a total result, they have high degrees of SLA, faster-performing storage and the info is readily accessible with lower-cost API calls (which we’ll discuss more shortly).

These aren’t the only real tiers available though. The storage tiers designed for each one of these clouds are the following from “hottest” to “coldest”:

• • Microsoft Azure
    • • Hot Tier
    • • Cool Tier
    • • Archive Tier

• • Amazon Web Services
    • • S3 Standard
    • • S3 Glacier
    • • S3 Deep Glacier

• • Google Cloud Platform
    • • Standard
    • • Nearline
    • • Coldline
    • • Archive

As these storage tiers get colder, several attributes change about them. The storage backing them may become lower performing and there could be delays between your requesting of the info and the option of the data. Note: That is dissimilar to read latency, this can be a right time delay prior to the data can be acquired to be accessed at all, as high as hours potentially. But that’s not absolutely all that’s different about them!

How exactly to determine API call types and requirements

When getting together with storage, either with a read or perhaps a write, you’re facilitating API calls actually, fetching or placing a block at the right time. So, how large is really a block? Well, the solution is of course, this will depend! Each storage provider could have a maximum block size supported individually; however, you’ll be guided by your configuration within Veeam. We’ll discuss this further along whenever we look at Veeam configurations, but automagically, expect 1MB to be 1 API call approximately.

So, how come this important? Because API calls cost money! Way more, the total amount they cost be determined by the storage tier you’re using (see previous section). The colder the storage, the more the API calls cost. These API calls are priced either per 10,000 calls (Azure/GCP) or per 1,000 calls (AWS).

Furthermore, when you opt to move data between tiers, this isn’t a “magic” or “free” operation. Each cloud provider differently handles this slightly, for instance in Azure, it is possible to demote data to a cooler tier and promote back again to a warmer tier then, whereas in AWS & GCP that is described a lifecycle transition and data can only just be migrated to colder tiers, never to warmer tiers back. Pricing is calculated for every as such:

• • Microsoft Azure ( Full details )
    • • Demoting Tier: Write Access (GB) and Write API calls derive from the expenses of the destination tier.
    • • Promoting Tier: Read Access (GB) and Read API calls derive from the costs of the foundation tier.

• • Amazon Web Services ( Pricing details )
    • • Lifecycle Transitions: A transition price is defined for the destination tier you intend to demote data to.

• • Google Cloud Platform ( Pricing details )
    • • Lifecycle Transitions: They are billed at the Class A operations charge rate of the destination storage tier.

In the last section now, I mentioned that we now have delays in retrieving archive tier data, this is by means of hours. That is commonly as the data must be rehydrated from the archive storage. However, with regards to the storage tier you utilise, it’s possible to generate expedited/high-priority requests at an increased cost per API call and GB read to lessen enough time delay to retrieve the initial byte and beyond. This isn’t on all platforms for several access tiers, so ensure that this option can be acquired before you factor it into your recovery plans.

Minimum data retention

Prior to going rushing ahead to calculate your storage costs to upload and wthhold the data, we have to discuss the restrictions on these tiers now, the colder ones particularly. Microsoft, Amazon and Google all expect any data being uploaded to these tiers to be retained for minimum intervals and there could be scenarios in which you think placing your computer data onto a colder tier helps you to save costs and soon you factor these in. The minimum retention periods for the various tiers are:

• • Microsoft Azure ( Full details )
    • • Hot Tier: No minimum retention
    • • Cool Tier: 1 month
    • • Archive Tier: 180 days

• • Amazon Web Services ( Full details )
    • • S3 Standard: No minimum retention
    • • S3 Glacier: 3 months
    • • S3 Deep Glacier: 180 days

• • Google Cloud Platform ( Full details )
    • • Standard: No minimum retention
    • • Nearline: 1 month
    • • Coldline: 3 months
    • • Archive: 365 days

This creates scenarios whereby additional charges could be incurred. For instance:

• • Deleting the info

• • Migrating the info to some other tier

• • (Azure Only) Promoting the info

If these scenarios are completed prior to the minimum retention periods are met, charges will undoubtedly be levied then, normally by means of pro-rated storage retention for the rest of the days. Review your unique tier and provider to find out more via the links above.

As your final note with this subject, these vendors differently calculate data retention, for instance GCP calculates data retention predicated on once the object was originally created of their storage platform, instead of when it had been migrated to the tier requiring the very least retention such as for example with Azure and AWS.

Data distribution options

Storage tiering isn’t the only real design consideration you’ll require when planning your using cloud storage, you can even choose your degree of redundancy for the data to withstand inside your platform of choice.

You’ll have the ability to distribute your computer data across different data centers within exactly the same region, known as different availability zones commonly. You’ll have the ability to distribute your computer data between entirely different regions also, to safeguard against a regional failure of one’s data. When protecting from regional failures, you’re not only protecting yourself from physical disaster to a spot, but additionally access issues such as for example networking or power conditions that isolate access to a specific region temporarily. Google Cloud Platform differs probably the most to Microsoft Amazon and Azure Web Services in this context, as the geo-redundancy you select for your storage will undoubtedly be specified by either selecting a region either, or perhaps a true name of a multi-region grouping. Your options available are:

• • Microsoft Azure ( Additional information )
    • • Locally Redundant Storage (LRS) – This is actually the cheapest storage option designed for Microsoft Azure, storing three copies of the info inside a single zone inside your selected region.
    • • Zone Redundant Storage (ZRS) – This storage will store your computer data inside a single Azure region, nonetheless it shall store the info three times, synchronously, between different Azure zones within the spot.
    • • Geo-Redundant Storage – This will copy the data to a single zone within the primary region synchronously, to LRS and asynchronously again inside a secondary region identically, to LRS identically.
    • • Geo-Zone-Redundant Storage – This will copy the data to three Azure zones within the primary region synchronously, identically to ZRS, whilst storing the info again inside a secondary region asynchronously, identically to LRS.

• • Amazon Web Services ( Additional information )
    • • S3 Availability Zones – Unless you decide to utilise a One Availability Zone redundancy class specifically, your data will be split between three different Availability Zones inside a region as standard. They are miles apart to avoid damage such as for example flood or fire from destroying all data inside a region.
    • • S3 Cross-Region Replication – This asynchronous copying of data lets you store multiple copies of data within different regions

• • Google Cloud Platform ( Additional information )
    • • Region – A single region in which your data shall be stored.
    • • Dual-Region – A dual region pre-grouped by Google.
    • • Multi-Region – Several pre-grouped regions by Google.

Immutability considerations

At present, only Amazon Web Services has immutability that’s supported by Veeam natively. S3-compatible storage can be supported by extension but Veeam specifically lists Microsoft Azure and Google Cloud Platform as unsupported during writing.

AWS Immutability functions by defining an immutable flag (known as an object lock) to the thing within the S3 storage bucket. Before you decide to enable this, you have to know what your alternatives are for getting together with immutability.

Immutability with Amazon Web Services could be presented in two flavours, Governance Mode and Compliance Mode. Governance Mode may be the softer of both modes and may be the mode I would suggest for testing purposes. With Governance Mode, in case a user has specific permissions to bypass governance retention, they’ll be permitted to overwrite the retention settings, like the removal of retention. With Compliance Mode, however, nobody, the root user even, can amend or take away the retention settings. This mode supplies the highest degree of security, but also probably the most risk if your policy hasn’t been configured needlessly to say.

Conclusion

To recap partly one, we’ve viewed the “big three” object storage providers, where they provide similarities and where they differ. Partly two, we’ll look at how making changes to Veeam shall influence the impact of the providers and the associated costs.