Question-14: When you begin to plan your migration to Google Cloud, the first thing you do is define the environments that will be a part of the migration. An on-premises environment, a private hosting environment, or another public cloud environment can serve as your starting point. You are moving applications hosted on third-party servers to Google Cloud from optimised virtual machines located on your premises. You are unsure which CPU and memory options will provide the best results. The applications have a pattern of use that is consistent across a period of multiple weeks. You want to get the most out of the resources you have while minimising your expenditures. What action should you take?
A. Construct an instance template with the smallest machine type that is currently accessible and make use of an image of the third-party application that was obtained from a live on-premises virtual machine. Develop a managed instance group that automatically adjusts the number of instances it contains based on the group's average CPU use. Adjust the threshold for the average CPU consumption in order to get the optimal number of instances operating.
B. Construct a flexible environment inside App Engine, and then deploy the third-party application by making use of a Dockerfile and a specialized runtime. In the app.yaml file, configure the CPU and RAM settings in a manner that is analogous to the virtual machine that is currently hosting your application on-premises.
C. Make many instances of Compute Engine, each with a different configuration of the CPU and RAM. Install the agent for Cloud Monitoring, and then install the third-party application on each of the devices individually. Conduct a load test on the application when it is experiencing high amounts of traffic, and then make use of the data to establish the best configuration options.
D. Make an instance of Compute Engine with the same CPU and memory configurations as the on-premises virtual machine that is currently hosting your application. First, install the agent for Cloud Monitoring, and then roll out the third-party application. Conduct a load test on the application using amounts of traffic that are typical for it, and then refer to the Cloud Console's Rightsizing Recommendations.
Correct Answer
Get All 340 Questions and Answer for Google Professional Cloud Architect
: 4 Explanation: The suggestions provided by rightsizing fall into two categories: 1. Recommends Compute Engine instances depending on the amount of CPU and RAM that is presently assigned to the on-premises virtual machine (VM). This advice serves as the fallback option. 2. Recommendations based on cost Compute Engine instances are recommended based on the following criteria: - The present CPU and RAM configuration of the on-premises virtual machine - The typical amount of work done on this VM during the course of the specified time period In order to make advantage of this choice, you will first need to enable rightsizing monitoring with vSphere for this particular set of virtual machines (VMs), and then you will need to give Migrate for Compute Engine enough time to evaluate how it is being used. Here's the point: 2. Recommendations that are based on cost Compute Engine instances are recommended to the user depending on the current CPU and RAM configuration of the on-premises virtual machine. Option 1: The programme may not be able to handle horizontal scalability, and it also might not be able to operate on instances with a limited number of CPU cores B. Dockerizing third-party apps is not a prerequisite. Complicated and expensive Option-3, it's just too pricey Option-4, easy, and it works. There would be no time for GCE to scale up before the database automatically terminated itself. You have the option of using a machine type that has already been specified, such as an e2-highmem-4, n2-highmem-4, or n2d-highmem-4. If the virtual machine needs four virtual CPUs and thirty-two gigabytes of RAM, there is no assurance that its performance will be comparable to that of an existing VM in the data center. The networking fabric, the disc I/O, and the CPUs themselves are all distinct from one another. We are unable to draw a parallel between the processors given by GCP and the CPUs used in the data centres since we do not know the precise specifications of the CPUs used in the data centers. As can be seen, the performance is quite sensitive to the frequency, which may result in a wide range of outcomes. (do you remember having to fork out an extra five hundred dollars to upgrade the CPU on your laptop from 2.6 gigahertz to 2.8 gigahertz? After moving to Google Cloud, you might come to the conclusion that you need fewer or more virtual CPUs than before, but until you make the move and put it through its paces, there is no way to know for sure which machine type will provide the best results. The advice that should be followed, therefore, is to begin with a low instance size and gradually increase it as necessary until the performance reaches an acceptable level; at that point, you will know the type of machine you are using.