Azure Stack with PowerScale
Tue, 04 Aug 2020 14:52:59 -0000|
Read Time: 0 minutes
Dell EMC Integrated System for Microsoft Azure Stack Hub has been at the forefront in bringing Azure to customer datacenters, enabling customers to operate their own region of Azure in a secure environment that addresses their data sovereignty and performance needs.
As data growth explodes at the edge, many of our customers are looking to process PB scale data in the context of file, image/video processing, analytics, simulation, and learning. With Azure Stack Hub, built on hyperconverged infrastructure (HCI), the need for external storage to handle this growth in data was critical. Additionally, for applications that use file storage with CIFS/NFS today, Azure files storage service is currently not supported.
As we set out to identify the right storage subsystem that met our customers’ needs (with performance, multi-tenancy, multi-petabyte scale-out storage, and advanced data management features), we did not have to look far. Dell Technologies has a large product portfolio that enables us not only to integrate with other infrastructures but to innovate in other areas to deliver the Azure consistent experience our customers expect.
With newly announced Azure Stack Hub integration with Dell EMC PowerScale, customers can run their Azure IaaS and PaaS on-premises while connecting to data that is generated and stored locally. In the context of Azure consistency, depending on your application needs, there are two ways to consume this storage.
- Azure Consistent Storage (ACS): Applications that are using Azure Block Blob storage
- Integrated NAS (File Storage): NFS and CIFS
Here are some highlights about the choices and differences:
Regardless of your protocol of choice, you have two personas engaged:
- The Azure Stack Hub Cloud administrator (screen below) is responsible for creating offers, quotas, and plans to offer the underlying storage, via subscriptions, to Azure tenants.
- The Azure Stack tenant can consume storage and be metered and billed consistent with other Azure Services. All of this, without having to manage anything in PowerScale.
With this strategy, our customers can tap into external PB storage to consume Azure Block Blob or Files via CIFS/NFS while maintaining the Azure consistent experience. Additionally, for customers looking to keep their applications in the public cloud while maintaining their data on-premises, Dell Technologies Cloud PowerScale extends OneFS running on-prem to Azure.
To read more about it, see this solution brief:
With the work Dell Technologies has been doing with Azure and Azure Stack Hub, your data is secure and compliant. You also have the choice to run your application in Azure or Azure Stack Hub and connect to your on-prem data without sacrificing bandwidth or latency.
Related Blog Posts
Automated Detection of Server Configuration Drift
Sun, 21 Jun 2020 15:57:53 -0000|
Read Time: 0 minutes
Automated Detection of Server Configuration Drift
Security and compliance are key design principles of Microsoft Azure Stack Hub. The Dell EMC Integrated System for Microsoft Azure Stack Hub is engineered to meet Compliance, Regulatory, and Policy requirements of our customers.
Security posture on Dell EMC Integrated system for Microsoft Azure Stack Hub is implicit to our automated lifecycle management. Our goal is to extend and complement Microsoft’s strategy of baselining and remediating their security posture with a comprehensive drift and remediation strategy for all of our Azure Stack Hub elements.
The Automated Server Config Drift Detection feature, enabled on Dell EMC OpenManage Enterprise as part of the Dell EMC Patch and Update Automation - 2004 Release, ensures Configuration Compliance as instituted by Microsoft and Dell EMC.
Monitor & Detect, Notify, and Remediate Server configuration Drift on Azure Stack Hub are the three key outcomes of the Automated Server config drift detection feature.
- Compliance Monitoring is kicked off by automated discovery of HLH and Scale Unit nodes on Dell EMC OpenManage Enterprise (Figure 1, below).
- Configuration integrity is maintained by enabling compliance baseline templates for the HLH and Scale Unit Nodes on OpenManage Enterprise in order to track drift (Figure 2).
- Customers can view Compliance reports which display whether Server settings conform to the configuration baseline or not (Figure 3).
- Drift from any of the Server settings applied at initial deployment on the HLH or Scale Unit nodes will be automatically detected, resulting in the node being tagged as Non-Compliant (Figure 4).
- Server-drift Notification Alerts generated on OpenManage Enterprise are sent proactively via Dell Support Assist Enterprise (SAE) to Dell Technologies support.
- Customers can call Dell EMC Support to remediate non-compliance to ensure that the health and compliance status of their Azure Stack Hub continues to stay green.
Figure 1: Monitor HLH and SU nodes discovered on OpenManage Enterprise for alerts
Figure 2: Configuration Compliance status of HLH and SU nodes against configuration baseline
Figure 3: Compliance report indicating SU Node level Compliance status
Figure 4: Drill down view of Compliance report in case of Compliance failures
Future updates to the compliance baseline are seamlessly applied by means of the Dell EMC Patch and Update Automation as customers update to the latest Dell EMC Customer Toolkit.
Stay tuned as we move the needle towards a well-rounded compliance experience for our customers with similar features on ToR and Management switches in upcoming releases.
Running containerized applications on Microsoft Azure's hybrid ecosystem - Introduction
Mon, 23 Mar 2020 22:39:11 -0000|
Read Time: 0 minutes
Running containerized applications on Microsoft Azure’s hybrid ecosystem
A vast array of services and tooling has evolved in support of microservices and container-based application development patterns. One indispensable asset in the technology value stream found in most of these patterns is Kubernetes (K8s). Technology professionals like K8s because it has become the de-facto standard for container orchestration. Business leaders like it for its potential to help disrupt their chosen marketplace. However, deploying and maintaining a Kubernetes cluster and its complimentary technologies can be a daunting task to the uninitiated.
Enter Microsoft Azure’s portfolio of services, tools, and documented guidance for developing and maintaining containerized applications. Microsoft continues to invest heavily in simplifying this application modernization journey without sacrificing features and functionality. The differentiators of the Microsoft approach are two-fold. First, the applications can be hosted wherever the business requirements dictate – i.e. public cloud, on-premises, or spanning both. More importantly, there is a single control plane, Azure Resource Manager (ARM), for managing and governing these highly distributed applications.
In this blog series, we share the results of hands-on testing in the Dell Technologies labs with container-related services that span both Public Azure and on-premises with Azure Stack Hub. Azure Stack Hub provides a discrete instance of ARM, which allows us to leverage a consistent control plane even in environments with no connectivity to the Internet. It might be helpful to review articles rationalizing the myriad of announcements made at Microsoft Ignite 2019 about Microsoft’s hybrid approach from industry experts like Kenny Lowe, Thomas Maurer, and Mary Branscombe before delving into the hands-on activities in this blog.
Services available in Public Azure
Azure Kubernetes Service (AKS) is a fully managed platform service hosted in Public Azure. AKS makes it simple to define, deploy, debug, and upgrade even the most complex Kubernetes applications. With AKS, organizations can accelerate past the effort of deploying and maintaining the clusters to leveraging the clusters as target platforms for their CI/CD pipelines. DevOps professionals only need to concern themselves with the management and maintenance of the K8s agent nodes and leave the management of the master nodes to Public Azure.
AKS is just one of Public Azure’s container-related services. Azure Monitor, Azure Active Directory, and Kubernetes role-based access controls (RBAC) provide the critical governance needed to successfully operate AKS. Serverless Kubernetes using Azure Container Instances (ACI) can add compute capacity without any concern about the underlying infrastructure. In fact, ACI can be used to elastically burst from AKS clusters when workload demand spikes. Azure Container Registry (ACR) delivers a fully managed private registry for storing, securing, and replicating container images and artifacts. This is perfect for organizations that do not want to store container images in publicly available registries like Docker Hub.
Leveraging the hybrid approach
Microsoft is working diligently to deliver the fully managed AKS resource provider to Azure Stack Hub. The first step in this journey is to use AKS engine to bootstrap K8s clusters on Azure Stack Hub. AKS engine provides a command-line tool that helps you create, upgrade, scale, and maintain clusters. Customers interested in running production-grade and fully supported self-managed K8s clusters on Azure Stack Hub will want to use AKS engine for deployment and not the Kubernetes Cluster (preview) marketplace gallery item. This marketplace item is only for demonstration and POC purposes.
AKS engine can also upgrade and scale the K8s cluster it deployed on Azure Stack Hub. However, unlike the fully managed AKS in Public Azure, the master nodes and the agent nodes need to be maintained by the Azure Stack Hub operator. In other words, this is not a fully managed solution today. The same warning applies to the self-hosted Docker Container Registry that can be deployed to an on-premises Azure Stack Hub via a QuickStart template. Unlike ACR in Public Azure, Azure Stack Hub operators must consider backup and recovery of the images. They would also need to deploy new versions of the QuickStart template as they become available to upgrade the OS or the container registry itself.
If no requirements prohibit the sending of monitoring data to Public Azure and the proper connectivity exists, Azure Monitor for containers can be leveraged for feature-rich monitoring of the K8s clusters deployed on Azure Stack Hub with AKS engine. In addition, Azure Arc for Data Services can be leveraged to run containerized images of Azure SQL Managed Instances or Azure PostgreSQL Hyperscale on this same K8s cluster. The Azure Monitor and Azure Arc for Data Services options would not be available in submarine scenarios where there would be no connectivity to Azure whatsoever. In the disconnected scenario, the customer would have to determine how best to monitor and run data services on their K8s cluster independent of Public Azure.
Here is a summary of the articles in this blog post series:
Part 1: Running containerized applications on Microsoft Azure’s hybrid ecosystem – Provides an overview of the concepts covered in the blog series.
Part 2: Deploy K8s Cluster into an Azure Stack Hub user subscription – Setup an AKS engine client VM, deploy a cluster using AKS engine, and onboard the cluster to Azure Monitor for Containers.
Part 3: Deploy a self-hosted Docker Container Registry – Use one of the Azure Stack Hub QuickStart templates to setup container registry and push images to this registry. Then, pull these images from the registry into the K8s cluster deployed with AKS engine in Part 2.