Azure Container Storage enabled by Azure Arc (preview) FAQ

Azure Container Storage enabled by Azure Arc is available in the following Azure regions:

• East US
• East US 2
• West US
• West US 2
• West US 3
• North Europe
• West Europe
• Australia East
• Germany West Central

If you previously installed a version of Azure Container Storage enabled by Azure Arc earlier than 2.1.0-preview, you must uninstall that previous instance in order to install the newer version. If you installed the 1.2.0-preview release or earlier, use these instructions. Versions after 2.1.0-preview are upgradeable and don't require this uninstall.

1. In order to delete the old version of the extension, the Kubernetes resources holding references to old version of the extension must be cleaned up. Any pending resources can delay the clean-up of the extension. There are at least two ways to clean up these resources: either using kubectl delete <resource_type> <resource_name>, or by "unapplying" the YAML files used to create the resources. The resources that need to be deleted are typically the pods, the PVC referenced, and the subvolume CRD (if Cloud Ingest Edge Volume was configured). Alternatively, the following four YAML files can be passed to kubectl delete -f using the following commands in the specified order. These variables must be updated with your information:

• YOUR_DEPLOYMENT_FILE_NAME_HERE: Add your deployment file names. In the example in this article, the file name used was deploymentExample.yaml. If you created multiple deployments, each one must be deleted on a separate line.

• YOUR_PVC_FILE_NAME_HERE: Add your Persistent Volume Claim file names. In the example in this article, if you used the Cloud Ingest Edge Volume, the file name used was cloudIngestPVC.yaml. If you used the Local Shared Edge Volume, the file name used was localSharedPVC.yaml. If you created multiple PVCs, each one must be deleted on a separate line.

• YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: Add your Edge subvolume file names. In the example in this article, the file name used was edgeSubvolume.yaml. If you created multiple subvolumes, each one must be deleted on a separate line.

• YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: Add your Edge storage configuration file name here. In the example in this article, the file name used was edgeConfig.yaml.

  kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
  kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
  kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
  kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
  

2. After you delete the files for your deployments, PVCs, Edge subvolumes, and Edge storage configuration from the previous step, you can uninstall the extension using the following command. Replace YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE, and YOUR_EXTENSION_NAME_HERE with your respective information:

   az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
   

If you previously installed a version of Azure Container Storage enabled by Azure Arc earlier than 2.1.0-preview, you must uninstall that previous instance in order to install the newer version.

1. Before you can delete the extension, you must delete your configPods, Persistent Volume Claims, and Persistent Volumes using the following commands in this order. Replace YOUR_POD_FILE_NAME_HERE, YOUR_PVC_FILE_NAME_HERE, and YOUR_PV_FILE_NAME_HERE with your respective file names. If you have more than one of each type, add one line per instance:

   kubectl delete -f "YOUR_POD_FILE_NAME_HERE.yaml"
   kubectl delete -f "YOUR_PVC_FILE_NAME_HERE.yaml"
   kubectl delete -f "YOUR_PV_FILE_NAME_HERE.yaml"
   

2. After you delete your configPods, PVCs, and PVs in the previous step, you can uninstall the extension using the following command. Replace YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE, and YOUR_EXTENSION_NAME_HERE with your respective information:

   az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
   

3. If you installed the extension before the 1.1.0-preview release (released on 4/19/24) and have a preexisting config.json file, the config.json schema changed. Remove the old config.json file using rm config.json.

The maximum number of files allowed in a Local Shared Volume is tied to the underlying storage limits. The maximum number of files is roughly 65,000 for every 1GB of provisioned storage capacity. Ingest subvolumes are subject to the same storage specific limitations (for example, 65,000 for every 1GB of provisioned storage capacity); however, they also have an upper limit based on metadata storage capacity. This limit is roughly 1.5-1.75 million files total.

It's important to note that this limit only applies to files currently stored in the subvolume. Generally, files are uploaded then purged. Therefore, this limit is mainly of note during disconnected scenarios or for subvolumes with long retention policies.

ACStor triplication stores data across three different nodes, each with its own hard drive. This intended behavior ensures data redundancy and reliability.

No, ACStor triplication isn't designed to operate on a single physical device with three attached hard drives.

No, Azure Container Storage enabled by Azure Arc doesn't support ARM deployments, at this time, Arc itself does not support ARM, so neither does this Arc extension.

There are three types of encryption that might be interesting for an Azure Container Storage customer:

• Cluster to Blob Encryption: Data in transit from the cluster to blob is encrypted using standard HTTPS protocols. Data is decrypted once it reaches the cloud.
• Encryption Between Nodes: This encryption is covered by Open Service Mesh (OSM) that is installed as part of setting up your Azure Container Storage cluster. It uses standard TLS encryption protocols.
• On Disk Encryption: Encryption at rest. Not currently supported by Azure Container Storage.

Yes, data in transit is encrypted using standard HTTPS protocols. Data is decrypted once it reaches the cloud.

Data persisted by the Azure Container Storage enabled by Azure Arc extension is encrypted at REST if the underlying platform provides encrypted disks.

When using Extension Identity, permissions as a StorageBlobDataOwner role are needed to write data. Is there a reason it needs Owner instead of just Contributor? Yes, the StorageBlobDataOwner role is required for metadata operations to store extended attributes.