Using Azure Tags with Everpure Cloud Dedicated

Everpure Cloud Dedicated for Azure

Audience
Public
Source Type
Documentation

What are Azure Tags?

Azure tags are metadata elements used to categorize resources within Microsoft Azure. They consist of a key-value pair, allowing users to label and organize their cloud resources in a meaningful way. Why is Tagging important?

Tagging offers significant advantages for deployments, including:

  • Cost Management: Facilitating the tracking and allocation of costs to specific departments, projects, or operational environments.

  • Resource Organization and Identification: Enhancing the ease of locating and managing CBS resources within complex Azure infrastructures.

  • Automation: Enabling automated operational processes based on defined tag values (e.g., the automated cessation or initiation of resources, the application of policies).

  • Policy Enforcement: Supporting the implementation of governance policies to ensure adherence to compliance standards and appropriate resource utilization.

  • Security: Strengthening security protocols by segmenting and controlling access to tagged resources.

How are Tags used in Azure?

Azure tags can be assigned at several scopes within your Azure environment, providing flexibility in how you organize and manage your resources. The main scopes where tags can be applied are:

  • Subscription level

    When you apply a tag at the subscription level, it doesn't automatically propagate to all resources within that subscription. Instead, it serves as a way to categorize the subscription itself.

    Use Case: This is useful for high-level organizational tagging, such as identifying the owner of a subscription, the cost center it belongs to, or its overall purpose (e.g., "Production-Environment-Subscription").

  • Resource group level

    Tags applied to a resource group can be inherited by resources deployed within that resource group. This is a common and effective way to ensure consistency.

    Use Case: Ideal for grouping related resources that share common characteristics, such as belonging to the same application, environment, or project.

  • Individual resource level

    Tags are applied directly to a specific Azure resource, such as a virtual machine, a storage account, or a Everpure Cloud Dedicated instance.

    Use Case: This allows for granular tagging where a resource might have unique attributes not shared by its resource group or subscription. For example, a specific Everpure Cloud Dedicated instance might have a tag indicating DataClassification: Confidential even if its resource group doesn't require this level of detail.

There are two supported mechanisms when to apply tags:

  • Deployment-time tagging: Tags are specified within the deployment templates (e.g., ARM or Bicep) and applied based on the resource type at creation time.

  • Post-deployment tagging: Tags are manually assigned to individual resources via UI, CLI, or API after they have been deployed.

It's crucial to understand that by default, there is no automatic inheritance, tags applied at a higher scope (like subscription or resource group) do not automatically cascade down to child resources unless specifically enforced by Azure Policy. Azure Policy is the primary mechanism to enforce tagging standards and ensure consistency across different scopes. You can use policies to:

  • Require tags: Mandate that specific tags must be present on resources, resource groups, or subscriptions.

  • Append tags: Automatically add specific tags to resources during creation or update if they are missing.

  • Inherit tags: Create policies that specifically copy tags from a resource group down to resources deployed within it.

  • Modify tags: Change existing tag values based on certain conditions.

Tagging behavior with Everpure Cloud Dedicated

Customers primarily utilize tags to organize resources for purposes such as cost allocation and reporting. Consequently, it is infrequent for resources of the same type to possess substantially disparate tags. This methodology aligns with Azure's tagging convention, whereby tags are applied at the time of deployment per resource type and generally adhere to a uniform pattern across various resource types.

The same behavior applies to Everpure Cloud Dedicated where several tags (especially tags beginning with PS_) are applied to individual resources (controller VMs, managed disks etc.) during the CBS deployment process. Those tags are critical and required for Everpure Cloud Dedicated functionality, they shouldn't be modified or removed otherwise it may result in a system failure.

What is changing?

Starting with upgrade-scripts version 8.1.10, Everpure Cloud Dedicated tagging behavior has changed. Before, customer tags were not persistent and were lost during Purity upgrades or during Non-Disruptive Controller Scaling procedure.

Now, when doing Purity upgrades or during Non-Disruptive Controller Scaling procedure, customer tags remains persistent. Also, an additional upgrade check is performed to check for existence of any conflicting tags on Everpure Cloud Dedicated resources. In case there are conflicting tags on resources of the same resourceType (i.e., same keys with different values or entirely different keys), an upgrade check error will be thrown (CbsTagsCheck). There is an option to bypass this upgrade check and proceed with the upgrade, with the understanding that only the common tags across all resources of a given resourceType will be preserved and any conflicting or unique tags will be lost.

An example of error when conflicting tags are found during upgrade:

pureuser@cbstest-1756786644:~# puresw upgrade show-step-detail
Software Name Step Name Step ID Check Name Check Status Overridable
Check Details
Purity//FA pre-upgrade check ace88048-8f61-41ba-948c-37343a1ceac7
CbsTagsCheck failed True Message: The upgrade cannot proceed because the
listed resources are non-compliant with tag usage. Please delete the
tags listed for each resource to proceed with the upgrade.
                {
                       "cbstest-1756786644": 
                        {
                                "gentagnotonvm": "true"
                         }
                }
Recommended Action: Delete the listed tags or proceed to ignore the
check and lose the non-compliant tags during upgrade.

How it works examples

In the table you can find an example showing how adding/modifying the tags works.

Action Change Type Original State Modified State after performing the action and before running an upgrade Final State after upgrade Logic Applied
Update Value Modify existing key {Key: Value} {Key: NewValue} {Key: NewValue} The system locates the existing Key and overwrites its associated value.
Update Key Add new Key Value {Key: Value} {NewKey: Value} {Key: Value} + {NewKey: Value} The system treats this as Create. The old key and value are retained, and a brand-new key-value pair is added.
Update Both Add new Key Value {Key: Value} {NewKey: NewValue} {Key: Value} + {NewKey: NewValue} The system treats this as Create. The old key and value are retained, and a brand-new key-value pair is added.
Add New Key Extension {Key: Value} {Key: Value} + {Key2: Val2} {Key: Value} + {Key2: Val2} A new entry is appended to the resource's tag collection.
Delete Remove Key {Key: Value} {} {Key: Value} Deleting a key Value pair is not supported.