This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
We are pleased to announce an update to the Azure HPC Cache service. We’ve received tremendous feedback from variety of customers and partners which has helped us drive these new capabilities.
HPC Cache helps customers enable High Performance Computing workloads in Azure Compute by providing low-latency high-throughput access to Network Attached Storage (NAS) environments. HPC Cache runs in Azure Compute, close to customer compute, but has the ability to access data located both in Azure as well as in customer datacenters.
Customer-Managed Key Encrypted Disks
HPC Cache disks are always encrypted, using standard platform-managed keys generated by Azure. Data is encrypted transparently using 256-bit AES Encryption.
Following the recent release of Server Side Encryption with customer-managed keys for Azure Managed Disks , we have integrated this capability with HPC Cache. Customers may set up an HPC Cache and choose keys from their own Key Vault to encrypt the disks. As described in the Managed Disks encryption documentation, envelope encryption uses a 256-bit platform data encryption key is protected by the customer provided key.
Key rotation is also supported for your individual caches, ensuring that you can rotate keys according to your security requirements.
Generally, HPC Cache network interfaces operate at the Azure default Maximum Transmission Unit (MTU) size of 1500 bytes. However, when using VPN connectivity, either to on-premises storage or across Azure regions, additional overhead is added to frames which requires a lower MTU setting. To address this, we have added the ability to choose between 1500 and 1400 bytes. The system can be changed only after installation and may be changed between the values. If you are not using VPN gateways it is unlikely that you need to change this value.
When a Network File System (NFS) environment leverages standard UID authentication, the superuser (root) identity represents a security risk if allowed to traverse systems. When enabled, root squash translates the superuser (UID = 0) to nobody (UID = 65534). Further, when enabled, root squash prevents privilege escalation by disallowing the use of set-UID permission bits in client requests.
Root squash is now enabled by default. If you have a cache older than April 4, 2020 you may need to enable this through the Azure Portal.
“Blob-as-POSIX” refers to HPC Cache’s unique ability to implement a 100% POSIX-compliant file system over a Blob container. Customers using HPC Cache and Blob-as-POSIX containers are essentially implementing a full-featured NFS NAS (network-attached-storage) solution.
Starting in April, customers leveraging Blob-as-POSIX will now inherit automatic snapshots. Automatic snapshots periodically record changes in the filesystem. These standard file-system snapshots will be accessible via individual.snapshot directories in your Blob-as-POSIX file system.
Automatic snapshots are on permanently and follow a standard schedule (UTC 0:00, 08:00 and 16:00). The snapshots are stored on a first-in-first-out basis. Up to 20 daily, 8 weekly and 3 monthly snapshots are retained.
Our team continues to add support for all API interfaces. We now support the use of Powershell to create, delete and manage HPC Cache instances.
Terraform (Terraform.io) is used to manage cloud resources. This third-party infrastructure automation service now includes the ability to create, manage, start/stop and delete HPC Cache instances.
Tell us about it!
Building features in HPC Cache that help support hybrid HPC architectures in Azure is what we are all about! Try HPC Cache, use it, and tell us about your experience and ideas. You can post them on our feedback forum.