Azure Virtual Machine Scale Sets now provide simpler management during scale-in

We recently announced the general availability of three features for Azure Virtual Machine Scale Sets. Instance protection, custom scale-in policy, and terminate notification provide new capabilities to simplify management of virtual machine instances during scale-in.

Azure Virtual Machine Scale Sets are a way to collectively deploy and easily manage a number of virtual machine (VM) instances in a group. You can also configure autoscaling rules for your scale set that enable you to dynamically increase or decrease the number of instances based on what the workload requires.

With these new features, you now have more control over gracefully handling the removal of instances during scale-in, enabling you to achieve better user experience for your applications and services. These new features are available across all Azure regions for public cloud as well as sovereign clouds. There is no extra charge for using these features with Azure Virtual Machine Scale Sets.

Let’s take a look at how these features provide you better control during scale-in.

Instance protection—protect one or more instances from scale-in

You can apply the policy Protect from scale-in to one or more instances in your scale set if you do not want these instances to be deleted when a scale-in occurs. This is useful when you have a few special instances that you would like to preserve while dynamically scaling in or out other instances in your scale set. These instances might be performing certain specialized tasks different from other instances in the scale set and you may want these special instances to not be removed from the scale set. Instance protection provides you the capability to enable such scenarios for your workload.

Protect one or more instances from scale-set actions

Instance protection also allows you to protect one or more of your instances from getting modified during other scale-set operations like reimage or upgrade. This can be done by applying the policy Protect from scale-set actions to specific instances. Applying this policy to an instance automatically also protects it from a scale-in.

Custom scale-in policy—configure the order of instance removal during scale-in

When one or more instances need to be removed form a scale set during scale-in, then instances are selected for deletion in such a way that the scale set remains balanced across availability zones and fault domains, if applicable. Custom scale-in policies allow you to further specify and control the order in which instances should be selected for deletion during scale-in. You can use the OldestVM scale-in policy to remove the oldest created instance first, or NewestVM scale-in policy to remove the newest created instance first. In both the scenarios, balancing across availability zones is given preference. If you have applied either of the protection policies to an instance, then it will not be picked up for deletion during scale-in.

Below are a couple examples of the scale-in order for a scale set with three availability zones and initial instance count 9. These examples assume that the VM with smallest instance ID was created first and that the VM associated with highest instance ID was created last. The VM instance enclosed in a dotted square represents that it has been protected using one of the instance protection policies. The cross indicates that the VM instance will be selected for deletion during scale-in.

 

Terminate notification—receive in-VM notification of instance deletion

When an instance is about to be deleted from a scale set, you may want to perform certain custom actions on the instance. Examples of these actions could be de-registering from the load balancer, or copying the logs, among others. When instance deletions are triggered by the platform, for example due to a scale-in, then these actions need to be programmatically performed to ensure that application does not get interrupted or useful logs are properly retained. With the terminate notification feature, you can configure your instances to receive in-VM notifications about upcoming instance deletion and pause the delete operation for 5 to 15 minutes to perform such custom actions on the instance.

The terminate notifications are sent through the Azure metadata service—Scheduled events—and can be received using a REST endpoint accessible from within the VM instance. Specific actions or scripts can be configured to run when an instance receives the terminate notification at the configured endpoint. Once these actions are completed and you do not want to wait for the pre-configured pause timeout to finish, then you can approve the deletion by issuing a POST call to the metadata service. This will allow deletion of the instance to continue.

Get started

You can enable these features for your scale set using REST API, Azure CLI, Azure PowerShell or Azure Portal. Below are the links to the documentation pages for detailed instructions.

Instance protection
Custom scale-in policy
Terminate notification

Quelle: Azure

Azure Blob Storage enhancing data protection and recovery capabilities

Enterprises, partners, and IT professionals store business-critical data in Azure Blob Storage. We are committed to providing the best-in-class data protection and recovery capabilities to keep your applications running. Today, we are announcing the general availability of Geo-Zone-Redundant Storage (GZRS)—providing protection against regional disasters and Account failover—allowing you to determine when to initiate a failover instead.

Additionally, we are releasing two new preview features: Versioning and Point in time restore. These new functionalities expand upon Azure Blob Storage’s existing capabilities such as data redundancy, soft delete, account delete locking, and immutable blobs, making our data protection and restore capabilities even better.

Geo-Zone-Redundant Storage (GZRS)

Geo-Zone-Redundant Storage (GZRS) and Read-Access Geo-Zone-Redundant Storage (RA-GZRS) are now generally available offering intra-regional and inter-regional high availability and disaster protection for your applications.

GZRS writes three copies of your data synchronously across multiple Azure Availability zones, similar to Zone redundant storage (ZRS), providing you continued read and write access even if a datacenter or availability zone is unavailable. In addition, GZRS asynchronously replicates your data to the secondary geo pair region to protect against regional unavailability. RA-GZRS exposes a read endpoint on this secondary replica allowing you to read data in the event of primary region unavailability.

To learn more, see Azure Storage redundancy.

Account failover

Customer-initiated storage account failover is now generally available, allowing you to determine when to initiate a failover instead of waiting for Microsoft to do so. When you perform a failover, the secondary replica of the storage account becomes the new primary. The DNS records for all storage service endpoints—blob, file, queue, and table—are updated to point to this new primary. Once the failover is complete, clients will automatically begin reading from and writing to data to the storage account in the new primary region, with no code changes.

Customer initiated failover is available for GRS, RA-GRS, GZRS and RA-GZRS accounts. To learn more, see our Disaster recovery and account failover documentation.

Versioning preview

Applications create, update, and delete data continuously. A common requirement is the ability to access and manage both current and previous versions of the data. Versioning automatically maintains prior versions of an object and identifies them with version IDs. You can restore a prior version of a blob to recover your data if it is erroneously modified or deleted.

A version captures a committed blob state at a given point in time. When versioning is enabled for a storage account, Azure Storage automatically creates a new version of a blob each time that blob is modified or deleted.

Versioning and soft delete work together to provide you with optimal data protection. To learn more, see our documentation on Blob versioning.

Point in time restore preview

Point in time restore for Azure Blob Storage provides storage account administrators the ability to restore a subset of containers or blobs within a storage account to a previous state. This can be done by an administrator to a specific past date and time in the event of an application corrupting data, a user inadvertently deleting contents, or a test run of a machine learning model.

Point in time restore makes use of Blob Change feed, currently in preview. Change feed enables recording of all blob creation, modification, and deletion operations that occur in your storage account. Today we are expanding upon our Change feed preview by enabling four new regions and enabling support for two new blob event types: BlobPropertiesUpdated and BlobSnapshotCreated.

This improvement now captures change records caused by the SetBlobMetadata, SetBlobProperties, and SnapshotBlob operations. To learn more, read Change feed support in Azure Blob Storage (Preview).

Point in time restore is intended for ISV partners and customers who want to implement their own restore workflow on top of Azure Storage. To learn more, see Point in time restore.

Build it, use it, and tell us about it

These new capabilities provide greater data protection control for all users of Azure Storage. The general availability release of GZRS adds region-replicated zone redundancy types. Account failover allows customers to control geo-replicated failover for their storage accounts. In addition, the previews of Versioning and Point in time restore allow greater control of data protection and restoration to a previous date and time.

We look forward to hearing your feedback on these features and suggestions for future improvements through email at AzureStorageFeedback@microsoft.com. As a reminder, we love hearing all of your ideas and suggestions about Azure Storage, which you can post at the Azure Storage feedback forum.
Quelle: Azure

Rancher Dedicated as a Service

kubernauts.sh – Rancher Dedicated as a Service is designed and built for those companies who have a need to seriously run a managed Kubernetes anywhere, either On-Prem or as a Cloudless service togehter for you or w…
Quelle: news.kubernauts.io