Cloud Computing Köln - Seite 1718 von 6997 - Neues zu Cloud Computing, Internet of Things und Technologien

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/