September 2022 - Seite 2 von 49 - Cloud Computing Köln

30. September 2022

Arize AI launches on Google Cloud Marketplace and more than doubles its use of Google Cloud in 12 months

Artificial intelligence (AI) and machine learning (ML) models have become incredibly advanced in the last decade. AI has transformed how we’re served ads, receive recommendations for care at the doctor, and even how we’re helped by customer support teams. With AI playing an increasingly prominent role in the lives of consumers, it’s critical that businesses and their data science teams are equipped with the technologies needed to proactively surface, troubleshoot and resolve ML model performance issues quickly and accurately. Enter Arize AI.Founded in 2020, startup Arize AI mission is to provide organizations with a production-grade infrastructure platform that helps organizations use AI/ML accurately by identifying and fixing any potential ML model issues quickly and seamlessly. Now, Arize is launching its platform on Google Cloud Marketplace, helping scale its product to users around the globe. The startup has also more than doubled its usage of Google Cloud over the last 12 months to meet growing demand for its products among its customers, including leading enterprises across industries including technology and financial services.With Arize’s ML observability platform, machine learning engineers can better understand how their deployed AI is–or isn’t–working. The platform connects offline ML training and validation datasets to customers’ online production data in a central inference store, which in turn enables ML practitioners to pinpoint the source of model performance problems as they surface. Using Arize, engineers can quickly identify issues like data drift and algorithmic bias, address data integrity issues impacting predictions, and improve model interpretability for optimized performance over time.With accelerated AI strategies on the rise at companies across numerous industries, Arize selected Google Cloud as its primary cloud provider so it could scale its cloud-first business with technologies like Google Kubernetes Engine (GKE). Since October 2021, the startup has been significantly expanding its usage of Google Cloud infrastructure and technologies to meet the growing demand for its platform. Today, Arize is furthering its partnership with Google Cloud in a few key ways in order to scale its business more rapidly in the cloud and continue delivering innovative platform advancements to its customers.First, Arize is today making its platform available on Google Cloud Marketplace, expanding its availability to customers globally. Leveraging Google Cloud’s go-to-market expertise, Arize will be able to increase revenues with greater scale and speed. Additionally, this expanded partnership will provide greater migration support to existing Arize customers as they move their on-prem Arize instances onto Google Cloud’s secure, global, and highly performant infrastructure. And for Google Cloud customers looking to get started with Arize, they can simply deploy the platform directly within their cloud environment and begin enhancing their ML observability capabilities.Secondly, Arize will continue to expand its use of GKE, which it uses for its developer hosting production environment and infrastructure support. With GKE, organizations are able to run fully-managed containerized applications with automation, at cloud scale, and on Google Cloud’s flexible, secure infrastructure. The platform elasticity enabled by GKE allows the Arize IT team–a small-but-mighty collective–to easily scale services up or down with demand and provide greater support to Arize developers at scale without getting bogged down with Kubernetes management.Arize also uses GKE as a part of its developer onboarding environment. Within GKE, Arize developers are equipped with a personal name space where they can run their own deployments of Arize using the full Arize stack, all within an isolated test environment. By aligning the company’s software testing and deployment standards with its developer onboarding practice, Arize developers are enabled with the skills and technologies needed to deploy new platform advancements quicker and with fewer bugs–resulting in consistently high developer efficiencies for the startup. Plus, the reliability of GKE abstractions allows Arize to remain nimble as their developer team grows and the business scales its software deployments. Besides leveraging Google’s secure infrastructure and GKE for its hosting production, developer onboarding, and application data management, Arize is also using Google Cloud tools like Cloud Storage to backup its application data, and Google BigQuery for internal analysis and back office services. As AI continues to change the way companies operate and deliver solutions to customers, Google Cloud is proud to support the growth of innovative startups like Arize with infrastructure and cloud technologies so they can empower business and their data science teams to drive accurate AI outcomes for the business and their customers.Click here to learn more about Arize on Google Cloud Marketplace, and why tech companies and startups choose Google Cloud here.Related ArticleWhy automation and scalability are the most important traits of your Kubernetes platformThe recipe for long-term success with Kubernetes: automation that matters and scalability that saves money.Read Article
Quelle: Google Cloud Platform

30. September 2022

da Agency

Introducing Workforce Identity Federation to easily manage workforce access to Google Cloud

At Google Cloud, we’re focused on giving customers new ways to strengthen their security posture. Managing identities and authorization is a core security control that underpins interactions inside and collaboration outside the organization. To address fraud, identity theft, and other security challenges associated with the proliferation of online accounts, many organizations have opted to use centralized identity provider (IdP) products that can help secure and manage identities for their users and SaaS applications, and we want to strengthen support for these solutions and the use cases they support.Today we’re pleased to announce Workforce Identity Federation in Preview. This new Google Cloud Identity and Access Management (IAM) feature can rapidly onboard workforce user identities from external IdPs and provide direct secure access to Google Cloud services and resources. Workforce Identity Federation uses a federation approach instead of Directory Synchronization, the method currently used by most organizations for onboarding Google Cloud identities. Workforce Identity Federation provides flexibility to support third-party collaboration use cases and business requirements that can be better addressed by using a localized, customer-managed IdP.Federating existing identities eliminates the need to maintain separate identities across multiple platforms. This means that organizations using Workforce Identity Federation no longer need to synchronize workforce user identities from their existing identity management solutions to Google Cloud. IdPs can include Identity-as-a-Service (IDaaS) and directory products such as those from ForgeRock, Microsoft, Okta, JumpCloud, or Ping Identity.Workforce Identity Federation overview and workflowWorkforce Identity Federation is another example of how we are working to make Google Cloud’s Invisible Security vision a reality, in this case delivering secure access leveraging customers’ current identity and access management solutions without the need for redundant user administration.VMware is one of our customers using Workforce Identity Federation in Preview. Thiru Bhat, director at VMware, explained why he’s excited for the new feature.VMware runs its own IdP and we needed a solution to allow our developers to access their Google Cloud projects while maintaining corporate control over identities and permissions. Syncing of user identities outside of our IdP is not permitted per our InfoSec policies and we deployed Google Cloud’s Workforce Identity Federation to fulfill our identity requirements. Workforce Identity Federation feature meets our needs with a solution that is robust and straightforward to configure.Here’s a closer look at a few use cases and the benefits from the new Workforce Identity Federation.Use case: Employee sign-in and authorization Streamlined authentication experience with fine-grained access controlWorkforce Identity Federation can enable your organization’s users to access Google Cloud through the same login experience they already use for their existing IdP for single sign-on. Workforce Identity Federation also can enable fine-grained access through attribute mapping and attribute conditions. Attributes — which some IdPs call claims — contain additional information about users. Google Cloud can use these attributes to further inform authentication decisions. Attribute mapping lets your administrators map identity attributes that are defined in your IdP to those that Google Cloud can use. Your administrators can configure Google Cloud with attribute conditions to authenticate conditionally — to let only a subset of external identities authenticate to your Google Cloud project based on attributes.For example, your administrators might want to let only those employees who are part of the accounting team sign in. To do this, your administrators can configure an IdP attribute, such as EmployeeJobFamily. Using attribute mapping, they could map this attribute to a similar attribute in Google Cloud, such as employee_job_family. Then, they could configure an attribute condition, assertion.employee_job_family==”accounting”.Use case: Secure access for partners and vendors Restricted and secure access to Google Cloud services from a partner or vendor that has their own IdP and associated privacy and data policiesToday, the modern enterprise depends on partners and vendors more than ever. Partners and vendors can help scale enterprise workflows, but they also can introduce new complexities for IT teams, such as how to secure partner or vendor identities in addition to the rest of their enterprise users. Workforce Identity Federation can enable enterprises to selectively federate users from partner or vendor IdPs without requiring enterprise IT teams to sync or create a separate identity store to use Google Cloud resources.One common scenario where Workforce Identity Federation can help is when a company hires a partner or vendor to provide outsourced development services using cloud resources (such as when Google Kubernetes Engine (GKE) DevOps services are outsourced to a partner.) The company creates a separate workforce pool for the partner or vendor’s administrator, who can then use their own IdP to grant access to their workforce.This use case can also help support organizations who have requirements to store and maintain identity information locally in support of data residency or digital sovereignty initiatives. By using a local IdP, either customer-managed or partner-managed, and federating identities to Google Cloud, organizations can further strengthen control over their identity information.Seamless experience for users, easy access management for administratorsBefore Workforce Identity Federation, organizations would need to duplicate user identities from their IdP by creating user accounts in Google Cloud Identity. Workforce Identity Federation can help you access Google Cloud without having to first create Cloud Identity user accounts. It also reduces toil by eliminating the need to maintain two separate identity management systems. Identity providers such as ForgeRock see tremendous value in the Workforce Identity Federation, and how Google Cloud can work with them to jointly help customers manage workforce identities. Peter Barker, ForgeRock’s Chief Product Officer, said that his company’s partnership with Google Cloud makes identity management easy and secure for administrators and users alike.“Our strategic partnership with Google Cloud delivers great value to our customers and we’re excited to continue to expand our relationship. This integration with Google Cloud Workforce Identity Federation enables ForgeRock customers to leverage their current IAM investments and makes it easier for employees, contractors, and partners to securely access Google Cloud resources.”Getting started with Workforce Identity FederationWorkforce Identity Federation is now available in Preview to customers already using Google Cloud. You can learn more about Workforce Identity Federation by visiting our webpage and watching this video.Please contact your account manager to see if workforce identity federation is the right fit for your organization. And, you can get started with these new capabilities today using our product documentation.Related ArticleIntroducing on-demand backup, schema extension support for Google Cloud’s Managed Microsoft ADSchema extension and on-demand backup/restore are now available with Managed Microsoft AD.Read Article
Quelle: Google Cloud Platform

30. September 2022

da Agency

Cloud Spanner doubles the number of updates per transaction

We are excited to announce that Cloud Spanner now supports 40,000 mutations per commit, double the existing limit at no additional cost. Cloud Spanner is a globally replicated, highly available, externally consistent ACID-compliant database. Customers across multiple sectors, including financial services and gaming, rely on externally consistent inserts, updates and deletes at scale to deliver fast and accurate experiences. A mutation represents a sequence of inserts, updates, and deletes that Spanner applies atomically to different rows and tables in a Spanner database. Cloud Spanner places limits on the number of mutations that can be included in a single transaction to ensure fast and consistent writes. Previously, queries were limited to 20,000 mutations per transaction, whether you were using DML via SQL or the lower-level Mutation API. We’ve doubled this limit to 40,000 to simplify batch updates and deletes. This is available to all customers of Cloud Spanner today. The size limit for each transaction remains unchanged at 100MB.What are mutations?Mutations are changes to values in the database. Cloud Spanner provides multiple ways to update data Standalone DML statements in transactions Batch DML statements to reduce the number of calls (and hence, round-trip latency) to the Spanner front-end Partitioned DML to automatically divide a large update into multiple transactions The programmatic Mutation API to change one or more cells at a time. A cell is an intersection of a row and a column. The API computes the cells to be updated from the user-provided rows and columns. Mutations across these approaches aggregate into the same mutations per transaction limit mentioned above. In the case of PartitionedDML, the mutation limit is not applied to the query itself, but Spanner enforces this limit when it creates the multiple transactions. For the other approaches, the user takes the responsibility. A single transaction may contain a combination of standalone and batch DML statements, in addition to programmatic API calls. Remember though, changes made with DML statements are visible to the subsequent statements.The DML or Mutation API describes the primary table that is impacted by the mutation. Interleaved tables and indexes on the affected columns also need to be updated as part of this transaction. These additional locations are referred to as effectors. You can think of effectors as those tables that are affected by the mutations, in addition to the target of the mutation. The mutation limit includes the changes to these effectors.Change streams watch updates in Spanner tables and write records of what changed elsewhere in the database in the same transaction. These writes are not included in the mutation limit.How can I estimate mutation counts?Spanner returns the mutation counts as part of the commit response message for a transaction. You can also estimate the number of mutations in a transaction by counting the number of unique cells updated across all the tables, including secondary indexes, as part of the transaction. Remember that a cell is the intersection of a row and column, like in a spreadsheet. A table that contains R rows and C columns, has R * C cells. Inserting a new row counts asC mutations since there are C cells in each row. Similarly, updating a single column counts as R mutations.More formally, if a commit consists of inserts to a primary table and one or more secondary indexes, the formula for calculating the number of mutations per commit is as follows.where R = number of rows/objects being inserted,C = number of columns updated as part of the transaction.Ii = number of secondary indexes on the current column.In other words, for each row, the update writes C cells in the primary table and one cell for each of the secondary indexes hanging off of the columns. For example, if an update touches 4 columns (regardless of the number of columns in the row) over 10 rows and two of those columns have secondary indexes, plugging into the formula above,where Ii is 1 for each of the 2 columns with secondary indexes and 0 for others. 4 * 10 + 2 * 10 = 60 mutations. Deletes are counted differently when it comes to logically adjacent cells. These are cells that are placed next to each other in table ordering and memory. Most common examples are logically adjacent cells are:Columns in a single rowConsecutive rowsInterleaved tablesDeletion of these cells count as a single mutation. So, deleting an entire row counts as one mutation. Deletions of cells that are not placed together, are still counted the same as insertions above. This means deletions of secondary indexes and foreign keys will count as one per cell. Deleting a column counts as R mutations, not including index deletions/changes.Is there a cost to using larger mutations?Transactions with more mutations involve more work. Since Spanner scales horizontally, much of this work can be distributed across multiple nodes. If this additional work causes instances to run hot, it may impact tail latencies for your application. Larger transactions need more memory and more compute cycles to write the additional bytes to disk. Mutations that are spread across the key space span multiple database splits. The transactions are guaranteed to be externally consistent but may take longer to complete. Account for these factors when constructing your transactions and scale up your instances to handle the additional load. Luckily Spanner can scale up or down in minutes without downtime and the compute capacity is prorated.Tip: When the number of mutations in a transaction is doubled, the transaction size doubles as well if no other changes are made.Mutations spread out across the key space or involving many indexes require coordination between the nodes (to maintain consistency). More specifically, different portions of the key space may be in different Paxos groups. In Spanner, each Paxos group achieves consensus through quorum. Reaching quorum in multiple Paxos groups takes time and the transaction will need to abort if any one of the Paxos groups is unable to reach quorum. Transactions with more mutations are more likely to include more Paxos groups.To summarize, large mutations are more resource intensive and can have measurably higher latencies. You can ameliorate these effects by reducing the size of the transaction and reducing the key-range of the mutations.What’s next?Congratulations! You learnt the different ways to write mutations, how to count them and how to compose transactions such that you can do more work in each transaction. Here are some things you should consider.If your application would benefit from the larger 40,000 mutation limit, increase the number of mutations in each transaction. Monitor the CPU usage and latencies to ensure that your instances are able to handle the additional load.Add more nodes, reduce transaction size and/or key space range for the transaction to improve these metrics.You can get started today for free with a 90-day trial or for as low as $65 USD per month.Related ArticleSpanner on a modern columnar storage engineGoogle’s planet-scale database, Spanner, was migrated to a modern columnar storage engine with many critical services running on top unin…Read Article
Quelle: Google Cloud Platform

30. September 2022

da Agency

How to get the most from your Intel-based instances on Google Cloud

Deploying mission-critical applications on Google Cloud can yield immediate benefits in terms of performance and total cost of ownership (TCO). That’s why Google Cloud is partnering with Intel to help our mutual customers optimize their most demanding workloads on Intel-based instances. The Intel Software Center of Excellence (CoE) for Google Cloud launched as a pilot in North America last year, and the results were dramatic — with an increase in Tensorflow inference performance for ad ranking algorithms, gain in throughput and reduction in latency for Redis under heavy loads and faster transcoding of videos to 1080p.Now, Intel and Google Cloud are expanding the program globally by opening it up to select high-growth enterprise accounts.The Intel Software Center of Excellence is a white-glove, high-touch program for customers looking to reduce latency and improve workload efficiency. This program is designed to enhance the value customers get from their Intel Xeon Scalable processors running in Google Cloud, offering them benchmarking and performance optimization techniques. It provides:Direct access to Intel engineers providing white-glove serviceGuidance for improving the price performance and the operational performance of Intel-based Google Cloud instancesCode-level recommendations on Intel processors so customers can experience the most benefit possible from their Google Cloud investmentsOptimizing the performance of your most demanding workloadsJoining the CoE program is an opportunity to work directly with Intel engineers to maximize the performance of your workloads on Intel instances in Google Cloud. Here are just a few examples of workloads that CoE participants are able to fine-tune and better manage performance through the program:Databases: Learn to use a wide variety of relational and nonrelational databases to address latency issues at peak loads or under complex conditions, such as Redis “latency knee” for e-commerce applications.Analytics: Get guidance on using Apache Spark.AI inference, including Recommendation, natural language processing, and vision recognition: Take advantage of Intel DL Boost in N2/C2 instances and Intel Math Kernel Library, and Tensorflow optimization.Secure web transactions: Built-in Intel crypto instructions can speed security processing for applications such as NGINX and WordPress.Language runtime libraries, including Golang Crypto, Java, and Python.Media, including video transcode, encode, and decode, as well as image processing, such as AVX-512 optimization and library optimizations like multithreading.”The collaboration between Intel, Google and Equifax utilizing the Intel Software CoE successfully optimized Equifax’s environment by producing nearly 2x throughput and a 50% drop in our critical metric for latency,” says Bryson Koehler, Chief Product, Data, Analytics & Technology Officer at Equifax. “The CoE met our objectives around cost optimization while improving performance SLAs for our end-customers.”How it worksThe Intel Software Center of Excellence engagement takes place in three phases:Phase 1: Discovery. The Google Cloud and Intel teams collaborate with you to review your performance objectives and identify key projects and long-term goals that may influence compute trends. Phase 2: Performance Review. Intel engineers leverage your metrics and Intel internal resources to review resource utilization across your service footprint. Phase 3: Performance report. The engagement concludes with the Intel team delivering a Performance Report, which includes detailed optimization recommendations, an action plan, and an implementation plan, and recommendations for potential support from Google Cloud Professional Services Organization (PSO), which can give operational guidance on getting the most value from your Google Cloud products.Get in touch to participateThe Intel Software CoE is open by application. Once your application is reviewed and accepted, there is no charge for the service. To participate, please complete the online application.Related ArticleThank you Partners for three years of growth and winning togetherGoogle Cloud Partner Advantage celebrates three years of continuous partner-led success through customer successes, Market Differentiatio…Read Article
Quelle: Google Cloud Platform

30. September 2022

da Agency

Introducing support for GPU workloads and even larger Pods in GKE Autopilot

Autopilot is a fully managed mode of operation for Google Kubernetes Engine (GKE). But being fully managed doesn’t mean that you need to be limited in what you can do with it! Our goal for Autopilot is to support all user workloads (those other than administrative workloads which require privileged access to nodes) so they can be run across the full GKE product.Many workloads, especially those running AI/ML training and inference require GPU hardware. To enable such workloads on Autopilot, we are launching support in Preview for the NVIDIA T4 and A100 GPUs in Autopilot. Now you can run ML training, inference, video encoding and all other workloads that need a GPU, with the convenience of Autopilot’s fully-managed operational environment.The great thing about running GPU workloads on Autopilot is that all you need to do is specify your GPU requirements in your Pod configuration, and we take care of the rest. No need to install drivers separately, or worry about non-GPU pods running on your valuable GPU nodes, because Autopilot takes care of GPU configuration and Pod placement automatically. You also don’t have to worry about a GPU node costing you money without any currently running workloads, since with Autopilot you are just billed for Pod running time. Once the GPU Pod terminates, so do any associated charges—and you’re not charged for the setup or tear down time of the underlying resource either.Some of our customers and partners have already been trying it out. Our customer CrowdRiff had the following to say:”CrowdRiff is an AI-powered visual content marketing platform that provides user-generated content discovery, digital asset management, and seamless content delivery for the travel and tourism industry. As users of Google Kubernetes Engine (GKE) and its support for running GPU-accelerated workloads, we were excited to learn about GKE Autopilot’s upcoming support for GPUs. Through our initial testing of the feature we found that we were able to easily take advantage of GPUs for our services without having to manage the underlying infrastructure to support this. Utilizing this functionality we expect to see reduced costs versus using standard GKE clusters and lower operational complexity for our engineers.” — Steven Pall, Reliability Engineer, CrowdRiffAnd our partner SADA comments:“Our recommendation to customers is to leverage Autopilot whenever possible because of its ease of use and the reduction of operational burden. The whole GKE node layer is offloaded to Google, and GPU pods for Autopilot enable an entirely new workload type to run using Autopilot. The Autopilot mode is an exciting enhancement for our customers to run their AI/ML jobs.” — Christopher Hendrich, Associate CTO, SADAUsing GPUs with AutopilotYou can request T4 and A100 GPUs in several predefined GPU quantities. You can accept the defaults for CPU and Memory, or specify those resources as well, within certain ranges. Here’s an example Pod that requests multiple T4 GPUs.code_block[StructValue([(u’code’, u’apiVersion: apps/v1rnkind: Deploymentrnmetadata:rn labels:rn app: tensorflowrn name: tensorflow-t4rnspec:rn replicas: 1rn selector:rn matchLabels:rn app: tensorflowrn template:rn metadata:rn labels:rn app: tensorflowrn spec:rn nodeSelector:rn cloud.google.com/gke-accelerator: nvidia-tesla-t4rn containers:rn – image: tensorflow/tensorflow:latest-gpu-jupyterrn name: tensorflow-t4rn resources:rn limits:rn nvidia.com/gpu: “4”‘), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e94cd877e10>)])]Listing 1: Simply specify your nvidia-tesla-t4 node selector and your pod will run on GPUThose few lines in your Kubernetes configuration is all you need to do! Just specify your GPU requirements in the PodSpec, and create the object via kubectl. Autopilot takes care of tainting GPU nodes to prevent non-GPU Pods running on them, and tolerating these taints in your workload specifications – all automatically. We will automatically provision a GPU-enabled node matching your requirements, including any required Nvidia driver setup.If for some reason your GPU Pod doesn’t become ready, check what’s going on with kubectl get events -w, and double-check that your resource values are within the supported ranges.Run Large Pods on Autopilot with the Balanced Compute ClassAnd GPU isn’t the only thing we’re adding today! Autopilot already supports a leading 28 vCPU maximum Pod size with the default compute, and up to 54 vCPU with the Scale-Out compute class, but we wanted to push the limits even higher for those workloads that need a bit extra. For those times when you need computing resources on the larger end of the spectrum, we’re excited to also introduce the Balanced compute class supporting Pod resource sizes up to 222vCPU and 851GiB! Balanced joins the existing Scale-Out compute class (which has a focus on high single-threaded CPU performance), and our generic compute platform (designed for everyday workloads).To get started with Balanced, simply add a node selector to your pods. Listing 2 is an example pod definition. Be sure to adjust the resource requirements to what you actually need though! Refer to this page for the pricing information of Balanced Pods.code_block[StructValue([(u’code’, u’apiVersion: apps/v1rnkind: Deploymentrnmetadata:rn name: nginx-arm64rnspec:rn selector:rn matchLabels:rn app: nginxrn template:rn metadata:rn labels:rn app: nginxrn spec:rn nodeSelector:rn cloud.google.com/compute-class: Balancedrn containers:rn – name: nginxrn image: nginx:latestrn resources:rn requests:rn cpu: 222rn memory: 851Gi’), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e94cd877950>)])]Listing 2: Run large pods using the Balanced compute classAs with GPU Pods, Autopilot automatically handles the placement of Balanced compute class Pods for you, so that you will only be charged the Balanced compute class prices for Pods that directly specify it. By default, Pods without the compute class nodeSelector will run on Autopilot’s original compute platform (where they can request up to 28 vCPUs).We can’t wait to see what you do with these new capabilities of GKE Autopilot.View our docs to read more about Autopilot GPU, and the new Balanced Compute Class.Related ArticleDeploying high-throughput workloads on GKE Autopilot with the Scale-Out compute classGKE Autopilot now offers compute classes for running containerized workloads on specialized compute platforms such as the Arm architecture.Read Article
Quelle: Google Cloud Platform

30. September 2022

da Agency

Ensure zone resilient outbound connectivity with NAT gateway

Our customers—across all industries—have a critical need for highly available and resilient cloud frameworks to ensure business continuity and adaptability of ever-growing workloads. One way that customers can achieve resilient and reliable infrastructures in Microsoft Azure (for outbound connectivity) is by setting up their deployments across availability zones in a region.

When customers need to connect outbound to the internet from their Azure infrastructures, Network Address Translation (NAT) gateway is the best way. NAT gateway is a zonal resource that is configured to subnets from the same virtual network, which means that it can be deployed to individual zones to allow outbound connectivity. Subnets and virtual networks, on the other hand, are regional constructs that are not restricted to individual zones. Subnets can contain virtual machine instances or scale sets spanning across multiple availability zones.

Even without being able to traverse multiple availability zones, NAT gateway still provides a highly resilient and reliable way to connect outbound to the internet. This is because it does not rely on any single compute instance like a virtual machine. Instead, NAT gateway leverages software-defined networking to operate as a fully managed and distributed service with built-in redundancy. This built-in redundancy means that customers are unlikely to experience individual NAT gateway resource outages or downtime in their Azure infrastructures.

To ensure that you have the optimal outbound configuration to meet your availability and security needs while also safeguarding against zonal outages, let’s look at how to create zone resilient setups in Azure with NAT gateway.

Zone resilient outbound connectivity scenarios with NAT gateway

Customer setup

Let's say you are a retailer who is preparing for an upcoming Black Friday event. You anticipate that traffic to your retail website will increase significantly on the day of the sale. You decide to deploy a virtual machine scale set (VMSS) so that way your compute resources can automatically scale out to meet the increased traffic demands. Scalability is not the only requirement you have in preparation for this event, but also resiliency and security. To ensure that you safeguard against potential zonal outages that could impact traffic flow, you decide to deploy these VMSS across multiple availability zones. In addition to using VMSS in multiple availability zones, you plan to use NAT gateway to handle all outbound traffic flow in a scalable, secure, and reliable manner.

How should you set up your NAT gateway with your VMSS across multiple availability zones? Let’s take a look at a few different configurations along with which setups will and won’t work.

Scenario 1: Set up a single zonal NAT gateway with your zone-spanning VMSS

First, you decide to deploy a single NAT gateway resource to availability zone 1 and your VMSS across all three availability zones within the same subnet. You then configure your NAT gateway to this single subnet and to a /28 public IP prefix, which provides you a contiguous set of 16 public IP addresses for connecting outbound. Does this setup safeguard you against potential zone outages? No.

Figure 1: A single zonal NAT gateway configured to a zone-spanning set of virtual machines does not provide optimal zone resiliency. NAT gateway is deployed out of zone 1 and configured to a subnet that contains a VMSS that spans across all three availability zones of the Azure region. If availability zone 1 goes down, outbound connectivity across all three zones will also go down.

Here’s why:

If the zone that goes down is also the zone in which NAT gateway has been deployed then all outgoing traffic from virtual machines across all zones will be blocked.
If the zone that goes down is different than the zone that NAT gateway has been deployed in, then outgoing traffic from the other zones will still occur and only virtual machines from the zone that has gone down will be impacted.

Scenario 2: Attach multiple NAT gateways to a single subnet

Since the previous configuration will not provide the highest degree of resiliency, you decide you will instead deploy 3 NAT gateway resources, one in each availability zone, and attach them to the subnet that contains the VMSS. Will this setup work? Unfortunately, no.

Figure 2: Multiple NAT gateways cannot be attached to a single subnet by design.

Here’s why:

A subnet cannot have more than one NAT gateway attached to it and it is not possible to set up multiple NAT gateways on a single subnet. When NAT gateway is configured to a subnet, NAT gateway becomes the default next hop type for network traffic before reaching the internet. Consequently, virtual machines in a subnet will source NAT to the public IP address(es) of NAT gateway before egressing to the internet. If more than one NAT gateway were to be attached to the same subnet, the subnet would not know which NAT gateway to use to send outbound traffic.

Scenario 3: Deploy zonal NAT gateways with zonally configured VMSS for optimal zone resiliency

What is the optimal solution then for creating a secure, resilient, and scalable outbound setup? The solution is to deploy a VMSS in each availability zone, configure each to their own respective subnet and then attach each subnet to a zonal NAT gateway resource.

Figure 3: Zonal NAT gateways configured to individual subnets for zonal VMSS provide optimal zone resiliency for outbound connectivity.

Deploying zonal NAT gateways to match the zones of the VMSS provides the greatest protection against zonal outages. Should one of the availability zones go down, the other two zones will still be able to egress outbound traffic from the other two zonal NAT gateway resources.

Summary of zone resilient scenarios with NAT gateway

Scenario

Description

Rating

Scenario 1

Set up a single zonal NAT gateway with your VMSS that spans across multiple availability zones but confined to a single subnet.

Not recommended: if the zone that NAT gateway is located in goes down then outbound connectivity for all VMs in the scale set goes down.

Scenario 2

Attach multiple zonal NAT gateways to a subnet that contains zone-spanning virtual machines.

Not possible: multiple NAT gateways cannot be associated to a single subnet by design.

Scenario 3

Deploy zonal NAT gateways to separate subnets with zonally configured VMSS.

Optimal configuration to provide zone resiliency and protect against outages.

FAQ on NAT gateway and availability zones

What does it mean to have a "no zone" NAT gateway?

"No zone" is the default availability zone selected when you deploy a NAT gateway resource. No zone means that Azure places the NAT gateway resource into a zone for you, but you do not have visibility into which zone it is specifically placed. It is recommended that you deploy your NAT gateway to specific zones so that you know in which zone your NAT gateway resource resides. Once NAT gateway is deployed, the availability zone designation cannot be changed.

If I have Load Balancer or instance-level public IPs (IL PIPs) on virtual machines and NAT gateway deployed in the same virtual network and NAT gateway or an availability zone goes down, will Azure fall back to using Load Balancer or IL PIPs for all outbound traffic?

Azure will not failover to using Load Balancer or IL PIPs for handling outbound traffic when NAT gateway is configured to a subnet. After NAT gateway has been attached to a subnet, the user-defined route (UDR) at the source virtual machine will always direct virtual machine–initiated packets to the NAT gateway even if the NAT gateway goes down.

Learn more

NAT gateway and availability zones.
Design virtual networks with NAT gateway.
Create a NAT gateway with the portal.

Quelle: Azure

30. September 2022

da Agency

Strengthen your security with Policy Analytics for Azure Firewall

This blog was co-authored by Gopikrishna Kannan, Principal Program Manager, Azure Networking.

Network security policies are constantly evolving to keep pace with the demands of workloads. With the acceleration of workloads to the cloud, network security policies—Azure Firewall policies in particular—are frequently changing and often updated multiple times in a week (in many cases several times in a day). Over time, the Azure Firewall network and application rules grow and can become suboptimal, impacting the firewall performance and security. For example, high volume and frequently hit rules can be unintentionally prioritized lower. In some cases, applications are hosted in a network that has been migrated to a different network. However, the firewall rules referencing older networks have not been deleted.

Optimizing Firewall rules is a challenging task for any IT team. Especially for large, geographically dispersed organizations, optimizing Azure Firewall policy can be manual, complex, and involve multiple teams across the world. Updates are risky and can potentially impact a critical production workload causing serious downtime. Well, not anymore!

Policy Analytics has been developed to help IT teams manage Azure Firewall rules over time. It provides critical insights and recommendations for optimizing Azure Firewall rules with a goal of strengthening your security posture. We are now excited to share that Policy Analytics for Azure Firewall is now in preview.

Optimize Azure Firewall rules with Policy Analytics

Policy Analytics helps IT teams address these challenges by providing visibility into traffic flowing through the Azure Firewall. Key capabilities available in the Azure Portal include:

Firewall flow logs: Displays all traffic flowing through the Azure Firewall alongside hit rate and network and application rule match. This view helps identify top flows across all rules. You can filter flows matching specific sources, destinations, ports, and protocols.
Rule analytics: Displays traffic flows mapped to destination network address translation (DNAT), network, and application rules. This provides enhanced visibility of all the flows matching a rule over time. You can analyze rules across both parent and child policies.
Policy insight panel: Aggregates policy insights and highlights policy recommendations to optimize your Azure Firewall policies.
Single-rule analysis: The single-rule analysis experience analyzes traffic flows matching the selected rule and recommends optimizations based on those observed traffic flows.

Deep dive into single-rule analysis

Let’s investigate single-rule analysis. Here we select a rule of interest to analyze the matching flows and optimize thereof.

Users can analyze Firewall rules with a few easy clicks.

Figure 1: Start by selecting Single-rule analysis.

With Policy Analytics, you can perform rule analysis by picking the rule of interest. You can pick a rule to optimize. For instance, you may want to analyze rules with a wide range of open ports or a large number of sources and destinations.

Figure 2: Select a rule and Run analysis.

Policy Analytics surfaces the recommendations based on the actual traffic flows. You can review and apply the recommendations, including deleting rules which don’t match any traffic or prioritizing them lower. Alternatively, you can lock down the rules to specific ports matching traffic.

Figure 3: Review the results and Apply selected changes.

Pricing

While in preview, enabling Policy Analytics on a Firewall Policy associated with a single firewall is billed per policy as described on the Azure Firewall Manager pricing page. Enabling Policy Analytics on a Firewall Policy associated with more than one firewall is offered at no additional cost.

Next steps

Policy Analytics for Azure Firewall simplifies firewall policy management by providing insights and a centralized view to help IT teams have better and consistent control of Azure Firewall. To learn more about Policy Analytics, see the following resources:

Get started with Azure Firewall and Policy Analytics.
Watch this video for a detailed walkthrough of the Policy Analytics capabilities.
Firewall Manager documentation.
Azure Firewall Standard features, Microsoft Learn.
Azure Firewall Premium features, Microsoft Learn.

Quelle: Azure

30. September 2022

da Agency

Simplified Deployment of Local Container Images to OpenShift

This guest post is courtesy of our friends over at Red Hat! They’re coming out with some exciting capabilities for the OpenShift Docker Extension and have even more planned in the future. Continue reading to learn more about what the OpenShift Extension is all about, its new features, and how to get started.

Simplified local container image deployment to remote OpenShift environments

Docker Desktop is a commonly used tool to build container images and run them locally. But oftentimes, you need to deploy your apps on an environment other than your localhost. One popular target is Kubernetes or OpenShift. So, as a developer and user of Docker Desktop, how can you deploy local containers onto remote OpenShift environments, without ever leaving the Docker Desktop UI? The answer lies in the Red Hat OpenShift Extension for Docker Desktop.

At Red Hat, we want to make the experience simple when developers target Kubernetes as the runtime environment for their containerized applications. Together with Docker Inc, we have developed the OpenShift Extension for Docker Desktop. This extension allows developers to deploy their Docker containers on a free Developer Sandbox for Red Hat OpenShift environment (that they can sign up for). Or they can use any other OpenShift cluster of their choice that they can configure. Developers can do all of this without leaving the Docker Desktop UI.

OpenShift Extension capabilities

The Red Hat OpenShift Extension for Docker Desktop enables developers who are working with OpenShift to deploy and test their apps with ease. From the extension UI, it just takes two steps to deploy your containerized app to OpenShift:

Choose Target OpenShift context. Choose the Docker image that you want to deploy to OpenShift.

The Red Hat OpenShift Extension provides the following capabilities:

Detection of Kubernetes environments: Scan your local kube-config file and preselect your current Kubernetes context. Users can also quickly switch from one environment to another. Login to Clusters: Users can connect to a new Kubernetes environment on their local workstation by directly using the connection details. The oc login command can be conveniently pasted into the Cluster URL field to automagically separate the URL and the bearer token parts into respective fields. Listing of projects (namespace): Browse and select the project in which you want to deploy your application.Selection of container images: Pick and choose the container image you already have built and pushed to a container registry. Deployment of container images: Generate resources needed to deploy your container images. Route gets generated automatically to expose your application outside of the cluster. Once deployed, the application automatically opens in a new browser tab. Push to DockerHub and deploy: Users can select the container image, push it to Docker Hub, and deploy to OpenShift in a single click.Push image to OpenShift registry and deploy: Users can select the container image, push it to OpenShift Registry, and deploy to OpenShift in one swift motion.Open the Console Dashboard: Quickly accessible from the extension UI, users can open the OpenShift Console Dashboard in the browser, if it’s exposed.Free access to OpenShift Developer Sandbox: Users can create a free account on OpenShift Developer Sandbox to get an OpenShift environment in the cloud.

Getting started with the OpenShift Extension

The following is a quick walkthrough covering setup and usage for the Red Hat OpenShift Extension for Docker Desktop.

Discovering and experimenting with Red Hat OpenShift

While the extension only works with Red Hat OpenShift, if you don’t have access to it — no worries, we’ve got you covered. You can sign-up for a free Red Hat Developer Sandbox and get an OpenShift environment in the cloud. No setup needed!

What the future holds on the extension

Red Hat is committed to adding more capabilities to the extension. One of our favorite features is Watch Mode. Using this feature, the extension will watch for changes in your source code and automatically build, push, and deploy the application on the preferred OpenShift cluster.

Get started with the Red Hat OpenShift Docker Extension

The Red Hat OpenShift Extension is available on the extensions marketplace. To get a free Red Hat OpenShift environment and try out the extension, explore our Red Hat Developer Sandbox.

Learn more and get involved

If you’d like to learn more about the OpenShift Extension for Docker Desktop, visit the following:

OpenShift Docker Desktop Extension RepositoryCheck out the on-demand session of Introducing Red Hat OpenShift Extension for Docker Desktop at DockerCon.

If you want to share your feedback, suggestions, and ideas or report an issue, please use the GitHub repository for the extension.

—

Want to learn more about Red Hat, other Docker Extensions, and more container-related topics? See the following for additional information.

Download and install Docker Desktop for Windows, Linux, or Mac. Find more details on the Red Hat OpenShift Extension. Read similar articles covering new Docker Extensions.Search for more handy extensions on Docker Hub. Learn how to create your own Docker Extensions.Check out the repository for the OpenShift Extension. Start a free developer sandbox for Red Hat OpenShift.
Quelle: https://blog.docker.com/feed/