da Agency

All together now: Fleet-wide monitoring for your Compute Engine VMs

Cloud Monitoring has always provided comprehensive visibility and management into individual Compute Engine virtual machines (VMs). But many Google Cloud customers have hundreds, thousands, or tens of thousands of VMs that they need to manage. Cloud Monitoring now gives you zero-config, out-of-the-box visibility into your entire Compute Engine VM fleet, with quick access to advanced Monitoring features such as installing the Cloud Monitoring agent and configuring fleetwide alerts. Our new Infrastructure Summary dashboard and expanded VM Instances dashboard jump-start your troubleshooting with no setup required!Monitor your VM fleet’s health with infrastructure summaryThe new single-pane-of-glass Infrastructure Summary dashboard lets you see aggregate fleet-wide statistics at a glance, and provides insight into the top VMs for a select group of key CPU, disk, memory, and network metrics. You can use the quick links in the top left to jump into detailed troubleshooting dashboards for load balancers, network, and VM instances. The filter bar enables you to narrow your view if you want to see a specific subset of VMs.Troubleshoot issues with VM instances fleet-wide viewYou’ve always been able to view and filter all your VM instances in Cloud Monitoring, and now you can do much more. The VM Instances dashboard now includes agent visibility and installation, and its new tabs let you see fleet-wide information across key metrics.View top VMs across key metrics for CPU, disk, memory, and networkDedicated tabs for CPU, disk, memory, and network show you outlier VMs for key metrics in each category, so you can visually inspect for anomalies and quickly drill into problem areas and VMs. Filtering allows you to narrow down the set of VMs being displayed in any tab for detailed analysis.View Monitoring agent status and install in the UIThe per-VM status of the Cloud Monitoring agent is now available in the main inventory page, and you can install the agent on a VM using our built-in wizard. Use the agent to track specified system and application metrics, including: Memory and disk metricsAdvanced system metricsMetrics for workloads like MySQL, Apache, Java virtual machine, and othersIf you want to install and manage the agent across multiple VMs at once, you can use our new Ops Agent Policies.Understand your advanced metricsThe “Explore” tab gives you insight into the advanced metrics you’re currently collecting in Cloud Monitoring, and quick links to information on how to send additional metrics, so you can see even more metrics in one place.Enable recommended alertsWe’ve made it easy to enable predefined recommended alerts across your whole VM fleet. With one click, you can ensure that all the VMs in your fleet are continuously monitored for excessive utilization (memory, disk, network, etc), and receive alert notifications across a variety of channels (email, SMS, Slack, PagerDuty, Cloud Console mobile app, Cloud Pub/Sub, and webhooks). You can also override recommended alert thresholds based on your needs.A fleet of new capabilitiesAs with all our operations tools, we want Cloud Monitoring to include everything you need to manage your environment, whether it consists of one VM or thousands. To get started with Cloud Monitoring, check out this demo.Related ArticleHigh-resolution user-defined metrics in Cloud MonitoringNow you can write custom and Prometheus metrics for Cloud Monitoring every 10 secondsRead Article
Quelle: Google Cloud Platform

da Agency

Anthos in depth: Easy load balancing for your on-prem workloads

For organizations that need to run their workloads on-prem, Anthos is a real game changer. As a hybrid multi-cloud platform that’s managed by Google Cloud, Anthos includes all the innovations that we’ve developed for Google Kubernetes Engine (GKE) over the years, but running in the customer’s data center. And as such, Anthos can integrate with your existing on-prem networking stack. One of the key pieces of integration is getting traffic into the Anthos cluster, which often involves using an external load balancer. When running Anthos on Google Cloud, you create a Kubernetes service accessible from the internet through Ingress or servicetype load balancer, and Google Cloud takes care of assigning the virtual IP (VIP) and making it available to the rest of the world. In contrast, when running Anthos on-prem, advertising the service’s VIP to your on-prem network happens using an external load balancer. Anthos provides three different options for deploying an external load balancer: the F5 Container Ingress Services (CIS) controller; manually mapping your load balancer to Kubernetes with static mapping; and Anthos’ own bundled load balancer.In this post, we’ll introduce these three options and dive deep into the Anthos bundled load balancer.F5 load balancingIn this mode, Anthos integrates with F5 by including the F5 Container Ingress Services (CIS) controller with Anthos running on-prem. This approach is ideal if you have an existing investment in F5 load balancing and want to use it with your Anthos on-prem cluster.Manual load balancingIf you have another third-party load balancer, you can manually map your external load balancer to your Kubernetes resources, allowing you to use the load balancer of your choice. As there is no controller here to map the Kubernetes resources to the external load balancer, you need to perform static mapping of the load balancer service.Anthos-bundled load balancingIn both the above modes, there are costs (licensing and hardware) and expertise associated with managing the external load balancer. More importantly, there can be organizational friction, both technical and non-technical, as external load balancers and Anthos clusters are often managed by different teams. Anthos’ bundled load balancer provides an option to customers who want to program the VIP dynamically, without having to configure or support a third-party option.The Anthos-bundled load balancer takes care of integrating external load balancer functionality as well as announcing the VIP to the external world. In contrast to the previous modes, Anthos itself now bridges the Kubernetes domain with the rest of your network. This approach brings several advantages: The team managing the on-prem Anthos cluster also manages the advertisement of VIPs. This mitigates the requirements for any tight collaboration and dependency between different organizations, groups and admins.Costs are streamlined, as you don’t have to manage a separate invoice, bill or vendor for your external load balancing needs.Simplified management, as Anthos controls both the controller as well as the VIP announcement. This has benefits in operational management, support, provisioning etc., making it a more seamless experience.Multinational investment banking firm HSBC uses Anthos’ bundled load balancer and reports that it’s easy to install and configure, with minimal system requirements. “Anthos running on-premises has brought the best of Google’s managed Kubernetes to our data centers. Specifically, the bundled load-balancer provides HSBC with a highly available, high performing, layer 4 load-balancer with minimal system requirements. Configuration and installation are simple and automate deployment for each new on-prem cluster. This decreases our time to market, installation complexity, and costs for each cluster we deploy.” – Scott Surovich Global Container Engineering Lead – HSBC Operations, Services & TechnologyUsing the Anthos bundled load balancer Using Anthos’ bundled load balancer on-prem is a relatively straightforward process.The bundled load balancer uses the Seesaw load balancer, which Google created and open sourced. In high availability mode, two instances run in active-passive pairs talking the standard Virtual Router Redundancy Protocol (VRRP). The passive instance becomes the active if it does not receive an advertisement from the active instance for two seconds, based on today’s default configuration.You can create a load-balancer-typed Kubernetes service to expose your application through the bundled load balancer. For example:Here, the bundled load balancer exposes a service to clients at port 80. The service config is sent to the load balancer automatically, which begins to announce SVIP by replying to ARP (address resolution protocol) requests. The load balancer runs in IPVS gatewaying mode (also known as “direct routing” mode), not touching the IP layer of packets and delivering packets to a Kubernetes node by modifying the destination MAC address. The advantage of running in this mode is that it doesn’t add any additional IP headers to the traffic, and therefore does not impact performance. The Kubernetes data plane (iptables in this case) on the node then picks up the packets destined to SVIP:80 and routes them to backends pods. Thanks to the gatewaying mode, the load balancer achieves “Direct Server Return (DSR)” and the responses bypass the load balancers. This saves capacity needed for the load balancers. Also because of DSR, the client IP can be visible in pods by setting “externalTrafficPolicy” to “Local” on the service.No external load balancer? No problemIf you don’t have an external load balancer that’s qualified for your network—or don’t have the in-house expertise to set one up—Anthos’ bundled load balancer can help. And thankfully, it’s easy to set up and use. Click here to learn more about Anthos’ networking capabilities, and stay tuned for our upcoming post, where we’ll show you how to use GKE private clusters for increased security and compliance.Related ArticleGKE best practices: Exposing GKE applications through Ingress and ServicesWe’ll walk through the different factors you should consider when exposing applications on GKE, explain how they impact application expos…Read Article
Quelle: Google Cloud Platform

da Agency

Migrate your custom ML models to Google Cloud in 3 steps

Building end-to-end pipelines is becoming more important as many businesses realize that having a machine learning model is only one small step towards getting their ML-driven application into production. Google Cloud offers a tool for training and deploying models at scale, Cloud AI Platform, which integrates with multiple orchestration tools like TensorFlow Extended and KubeFlow Pipelines (KFP). However, it is often the case that businesses have models which they have built in their own ecosystem using frameworks like scikit-learn and xgboost, and porting these models to the cloud can be complicated and time consuming. Even for experienced ML practitioners on Google Cloud Platform (GCP),  migrating a scikit-learn model (or equivalent) to AI Platform can take a long time due to all the boilerplate that is involved. ML Pipeline Generator is a tool that allows users to easily deploy existing ML models on GCP, where they can then benefit from serverless model training and deployment and a faster time to market for their solutions.This blog will provide an overview of how this solution works and the expected user journey, and instructions for orchestrating a TensorFlow training job on AI Platform. OverviewML Pipeline Generator allows users with pre-built scikit-learn, xgboost, and TensorFlow models to quickly generate and run an end-to-end ML pipeline on GCP using their own code and data. In order to do this, users must fill in a config file describing their code’s metadata. The library takes this config file and generates all the necessary boilerplate for the user to train and deploy their model on the cloud in an orchestrated fashion using a templating engine. In addition, users who train TensorFlow models can use the Explainable AI feature to better understand their model.In the figure below, we highlight the architecture of the generated pipeline. The user will bring their own data, define how they perform data preprocessing, and add their ML model file. Once the user fills out the config file, they use a simple python API to generate self-contained boilerplate code which takes care of any preprocessing specified, uploads their data to Google Cloud Storage (GCS), and launches a training job with hyperparameter tuning. Once this is completed, the model is then deployed to be served and, depending on the model type, model explainability is performed. This whole process can be orchestrated using Kubeflow Pipelines.Click to enlargeStep-by-step instructionsWe’ll demonstrate how you can build an end-to-end Kubeflow Pipeline for training and serving a model, given the model config parameters and the model code. We will build a pipeline to train a shallow TensorFlow model on the Census Income Data Set. The model will be trained on Cloud AI Platform and can be monitored in the Kubeflow UI. Before you beginTo ensure that you are able to fully use the solution, you need to set up a few items on GCP:1. You’ll need a Google Cloud project to run this demo. We recommend creating a new project and ensure the following APIs are enabled for the project: Compute Engine AI Platform Training and PredictionCloud Storage 2. Install the Google Cloud SDK so that you can access required GCP services via the command line. Once the SDK is installed, set up application default credentials with the project ID of the project you created above.3. If you’re looking to deploy your ML model on Kubeflow Pipelines using this solution, create a new KFP instance on AI Platform Pipelines in your project. Note down the instance’s hostname (Dashboard URL of the form [vm-hash]-dot-[zone].pipelines.googleusercontent.com).4. Lastly, create a bucket so that data and the models can be stored on GCS. Note down the bucket ID.Step 1: Setting up the environmentClone the github repo for the demo code, and create a Python virtual environment.Install the ml-pipeline-gen package.The following files are of interest to us to be able to get our model up and running:1. The examples/ directory contains sample code for sklearn, Tensorflow and XGBoost models. We will use the examples/kfp/model/tf_model.py  to deploy a TensorFlow model on Kubeflow Pipelines. However, if you are using your own model you can modify the tf_model.py file with your model code. 2. The examples/kfp/model/census_preprocess.py downloads the Census Income dataset and preprocesses it for the model. For your custom model, you can modify the preprocessing script as required. 3. The tool relies on a config.yaml file for the required metadata to build artifacts for the pipeline. Open the examples/kfp/config.yaml.example template file to see the sample metadata parameters and you can find the detailed schema here. 4. If you’re looking to use Cloud AI Platform’s hyperparameter tuning feature, you can include the parameters in a hptune_config.yaml file and add its path in config.yaml. You can check out the schema for hptune_config.yaml here.Step 2: Setting up required parameters1. Make a copy of the kfp/ example directory2. Create a config.yaml file using the config.yaml.example template and update the following parameters with the project ID, bucket ID, the KFP hostname you noted down earlier, and a model name.Step 3: Building the pipeline and training the modelWith the config parameters in place, we’re ready to generate modules that will build the pipeline to train the TensorFlow model. Run the demo.py file.The first time you run the Kubeflow Pipelines demo, the tool provisions Workload Identity for the GKE cluster which modifies the dashboard URL. To deploy your model, simply update the URL in config.yaml and run the demo again. The demo.py script downloads the census dataset from a public Cloud Storage bucket, prepares the datasets for training and evaluation as per examples/kfp/model/census_preprocess.py, uploads the dataset to the Cloud Storage URLs specified in config.yaml, builds the pipeline graph for training and uploads the graph on the Kubeflow Pipelines application instance as an experiment. Once the graph has been submitted for a run, you can monitor the progress of the run in the Kubeflow Pipelines UI. Open the Cloud AI Platform Pipelines page and open the Dashboard for your Kubeflow Pipelines cluster.Note:If you would like to use the Scikit-learn or XGBoost examples, you can follow the same steps above, but modify the examples/sklearn/config.yaml with similar changes as above without the additional step of creating a Kubeflow Pipelines instance. For more details, refer to the instructions in the public repo or follow our end-to-end tutorial written in a Jupyter notebook. ConclusionIn this post we showed you how to migrate your custom ML model for training and deployment to Google Cloud in three easy steps. Most of the heavy-lifting is done by the solution, where the user simply needs to bring their data, model definition and state how they would like the training and serving to be handled. We went through one example in detail and the public repository includes examples for other supported frameworks. We invite you to utilize the tool and start realizing one of the many benefits of Cloud for your Machine Learning workloads. For more details, check out the public repo. To learn more about Kubeflow Pipelines and its features, check out this session from Google Cloud Next ‘19.AcknowledgementsThis work would not have been possible without the hard work of the following people (in alphabetical order of last name): Chanchal Chatterjee, Stefan Hosein, Michael Hu, Ashok Patel and Vaibhav Singh.Related ArticleExplaining model predictions on image dataA conceptual overview and technical deep dive into how XAI works on image dataRead Article
Quelle: Google Cloud Platform