VMware Certified Associate 6

6. Clusters

In this video, I'll explain the concept of host clustering and how it can be used for availability, performance, and storage purposes. A cluster is simply a logical grouping of ESXi hosts. So let's say, for example, we have this group of four hosts that you see in our slide, and you want to automate certain aspects of how virtual machines run on those hosts. If any of these hosts fails, we want to restart the virtual machines that are running on that host on other hosts. We want to protect ourselves from a host failure by rebooting any affected VMs on other hosts. This is called "high availability," and it's one of the features supported on a host cluster. Or maybe we want to automatically move virtual machines around in case one of these hosts starts to get overwhelmed. Maybe we want to ensure that we have an equal workload on all four of these hosts at all times, and we don't want to manually monitor and move VMs around ourselves. We want it to happen automatically. We can do that by creating an aDRS, or Distributed Resource Scheduler, cluster. We can also take advantage of certain storage features by creating a cluster. So let's say, for example, you don't want to invest in a hardware storage array but you want to use the local storage and local SSD capacity of a group of ESXi hosts and leverage that local storage to create shared storage so that you can support features like DRS or V Motion. We can do that by creating a virtual San cluster. These are all clustering features that we'll spend more time on as we work our way through the remainder of this course. But for now, the main thing to understand is that we can create a host cluster using Vcenter to logically group together a number of ESXi hosts. And by grouping them together, we can enable features like Ha, D, Rs, and Virtual San.

7. Distributed Resource Scheduler

In this video, I'll introduce you to the Vsphere distributed Resource Scheduler, or DRS, feature. And DRS is really a fairly simple feature. Now, it takes some work to properly implement, but essentially what DRS provides us with is Vmotion and load balancing purposes. So for example, let's say that we have two ESXi hosts shown in the slide, and in reality, we would probably have more hosts than this. But, in essence, DRS will do the following: if efxi host one becomes overburdened, we can use Vmotion to load balance. We can take this virtual machine and we can migrate it to a different host with no downtime. That's one of the main purposes of the motion, to allow us to load balance across ESXi hosts. But identifying when these votes need to happen, identifying when there's an imbalance across multiple ESXi hosts, becomes increasingly difficult as your environment gets larger and larger. That's where DRS comes in. For the purposes of load balancing, DRS will automatically move virtual machines from host to host. And Vmotion is really the bedrock of DRS. So we have to make sure our VMs are voting compatible. So things like local ISO images, things like mismatched processors, things like insufficient bandwidth on ourconnection, can all impose some limitations or compatibility issues when it comes to Vmotion. And you'll notice here at the bottom of your screen it says CVMR Knowledge Base Article 100-3684 for common v.Motion errors. That will walk you through a lot of the kinds of V-motion incompatibility issues that you could potentially run into. It's not really covered on the VMware Certified AssociateExam, so I don't spend a lot of time on it here, but check out that Knowledge Basearticle or also check out www.trainertests.com. Udemy for information on where you can get additional resources. DRS comes in a few different flavors. We've got manual mode, right? And with DRS Manual Mode, what you're looking to do is enable DRS so that it can load balance across a cluster. But maybe you're not entirely comfortable allowing it to happen automatically. Maybe you don't want virtual machines being V motioned all over your cluster in the middle of the day, or maybe you're just not comfortable with DRS enough to allow it to take over at this point. But in the future, you might go with a fully automated mode. Manual Mode is a good starting point because manual mode does not do anything automatically. What it does is it analyses the performance of your cluster and it gives you recommendations, and you can choose whether or not you want to carry out those recommendations in partially automated mode. This is a little bit more automation than you get with Manual mode. Basically, what it means is that when you power on a virtual machine for the first time,it's automatically placed on the ideal host. So DRS will do a little bit of automation here. Basically, just saying, hey, somebody just powered on a new VM. You don't have to pick which host to power it on. DRS will automatically select the ideal host for you. Now, with fully automated mode, this is like putting it on autopilot. You're telling your cluster, "Okay, V Center is going to monitor this cluster." And if a performance improvement can be made by migrating a VM, then DRS will automatically use VMotion to migrate that VM to the ideal host. And so, in fully automated mode, we are turning over control to DRS and saying, load balance this cluster automatically for us. There's no manual approval of these changes. They just happen. So you can choose any one of those three different automation levels. You can also specify certain affinity or antiaffinity rules. For example, when I enable DRSon a cluster, I have to think about which virtual machines should be separated. So, for example, here we have two Domain Controller virtual machines. The Domain controller is running on ESXi 3. One Domain Controller Two is running on ESXi Four. But DRS has the keys now, and it can move virtual machines wherever it sees fit. So, if I just let DRS do whatever it wants, it might take Domain ControllerOne and Domain ControllerTwo and put them on the same host for load balancing purposes. And if the host were to fail, I would now have lost both of my domain controllers. Now, they may boot up on other hosts,but for at least a little while, my environment has no running domain controllers. Now with an anti-affinity rule, with the anti-affinity rule, what it will do is basically tell DRS theseVMs need to run on different hosts. And so in that way, DRS will never automatically migrate these two VMs to the same host. It'll keep them separated for redundancy purposes. And those are virtual machineaffinity or anti-affinity rules. Affinity rules. Keep virtual machines together. Anti-affinity rules keep them apart. So how does V Center fit into this picture? Well, we'll use V Center with the VSA web client to create a cluster and enable DRS on it. And once we've enabled DRS and fully automated mode,my virtual machines will start migrating around on myESXi hosts according to what DRS thinks is correct. As a result, DRS employs Vmotion as its underlying mechanism, and both DRS and V motion necessitate V center. As a result, the V centre fails. DRS does not operate. DRS doesn't work without Vcenter. Neither does V motion. Okay? So in review, in this lesson, we learned a little bit about DRS. We learned how it can automatically Vmotion virtual machines across hosts for load balancing. We learned about anti-affinity rules and how they can be used to segregate redundant VMs and keep them on separate hosts. Another important characteristic of DRS is that it makes it really easy to put a host into maintenance mode or do upgrades, because we can use DRS to automatically evacuate a host. DRS supports manual, partially automated, and fully automated bones, and it can automatically evacuate an ESXihost when it's placed in maintenance mode. to make things like Update Manager work better. And as we learn more and work our way through this course, you'll see that DRS and HighAvailability are two features that work really well together. So we haven't really covered Ha yet. But as we go a little further in this course,we'll learn about how these two technologies work together.

8. Distributed Power Management

In this video, I'll introduce you to Distributed Power Management, and the VMware Certified Associate Level Exam really focuses on your having an understanding of many features. You don't have to be an expert on any particular feature. You have to understand the basics of a lot of different features and what their use cases are. And distributed power management is one of those features. So here's how DPM works. First off, you have to have a DRS enabled cluster. We have to enable the distributed resource scheduler. And once that's enabled, we can enable DPM, or distributed power management. And here's how distributed power management works. Maybe during some hours of the day, like let's say at noon Eastern, you have these four ESXi hosts that are very heavily utilized. You have a lot of people at the office and a lot of customers, and things are chugging right along. And you really need all four of these ESXi hosts and the resources of all four ESXi hosts. But after 06:00 P.M. or 07:00 P.M., when the workload really starts to dwindle, maybe the average utilisation of these hosts goes down to like 30% or 40%. The usage drops after a certain hour, and at that point,it would be ideal if we wanted to save some power. Maybe we can take some of these ESXi hosts and power them off. So let's say that DPM has concluded, after monitoring for a while, that we could power off ESXi Four, and that the performance impact of doing so would be minimal. What DPM will do is it will place this host into what we call "standby." And in standby mode, what happens if ESXi Four is powered off? It's powered off. It's not working. And all of the virtual machines that were running on ESXi Four were vmotioned to other hosts, so that all the VMs are still running. But because the usage is so low, we don't need as much horsepower as we normally would during business hours to actually run all of those virtual machines. So, during periods of slow usage, one or more of the EssexI hosts in this cluster could potentially enter Standby Mode, in which case the host is actually powered off. Now, let's say fast forward to 8 a.m. the next morning, and usage is starting to ramp up. Our resource demands are starting to get higher. At that point, DPM will bring that fourth host back out of standby mode using Wake on Land. So essentially, a command will be sent to that host by the V centre saying, "Good morning, it's time to wake up, it's time to power back on." And then the host will power back on, and then DRS will start to do its thing and balance the workload across that cluster by moving VMs back to ESXi Four. And then we'll run at full strength during the busiest parts of our day. That's really the purpose of DPM: to automatically power off hosts when they're not needed and automatically bring them back out of standby mode when they are needed. Bye.

9. Resource Pools

In this video, we'll learn about resource pools in V apps. Resource pools are container objects that are used to group together virtual machines for a few different purposes. And the primary purpose is to assign resourcecontrols on a wider scale so we can use resource settings like shares, limits, and reservations to control the prioritisation of certain VMs. We may want them to get more memory than other VMs so they get higher priority access to memory or CPU, right? And in those cases, we're going to give VMs a higher number of shares. Or if we want to place a cap on a certain resource for VM, we can set a limit. Or if we want to guarantee certain resources for a VM, we can assign a reservation. But these resource controls become a little bit unmanageable if you continue to try to control them at an individual virtual machine level. So as your environment scales up, you may want totake advantage of resource pools in order to apply aset of controls across a wide variety of virtual machines. That's really what resource pools are all about: to allow us to create these resourcecontrols across a group of virtual machines. So maybe we need to guarantee performance for some critical VMs, or we want to create a resource pool where we set some kind of memory or CPU limit for non-essential workloads. There are all sorts of use cases that we might use resource pools for. We can also apply access controls to a resource pool. So for example, let's say you create a resource pool and it's got all of your database virtual machines in it, and maybe we'll give it a high number of shares because we want these database VMs to perform really well. Maybe we'll give it certain reservations to guarantee it a certain amount of resources. We can also apply access controls at the pool level, and those access controls will be applied to all of the virtual machines within that pool. So, for example, let's say we've got a group of database administrators and we want them to be able to open consoles to all these database VMs and we want them to be able to power them on and off and install VMware tools, so on and so forth. Well, what we can do is we can give them permission at the resource pool level and they will get that permission for every virtual machine within that resource pool. So resource pools are a nice way to conveniently control permissions as well. Okay, so let's take a look at an example of a resource pool, or actually two resource pools. So here in this image, we see we have an ESXi host with 48 gigs of memory. I've got a group of development virtual machines on the left and a group of production virtual machines on the right. And if I'd like to, I can take those development virtual machines and maybe place them all inside of a resource pool. And that resource pool can be used to set a memory limit. So maybe at any given time, I do not want the development machines to use more than 16 gigs of my host memory. I want to make sure at least 32 gigabits are available at all times for other things. So I can place those Dev VMs in a resourcepool, put a memory limit on them, and I've just controlled the entire amount of memory that those virtual machines as a whole are able to consume. Or I could do something a little bit more flexible,like assigning a share structure to the two pools. So in this case, I'm not putting any kind of hard and fast limits or reservations out there. What I'm doing is I'm saying, you know what,the Devpool is less important than the production pool. So maybe I'll give the development pool 20 memory shares and I'll give the production pool 40 memory shares. And if my ESXi host happens to be running low on memory, if I'm in a scenario where there's memory contention, well, based on my share structure that I've identified here, the production resource pool will get twice as much memory as the development pool. That's only going to happen if the ESXi host actually has memory contention occurring. If there's actually a shortage of resources, that's the only time those share values are actually enforced. So this is a more flexible model than the kind of hard-lined, strict limits and reservations. And so, during times of contention, here's the memory that each resource pool would get. The Dev pool would get 16 gigs. The prod pool would get 32 gigs based on their share values. I can even create a child pool within an existing resource pool, add virtual machines to it, and assign share limits and reservations to that child pool. And what will happen is the child pool will actually draw upon the resources of its parent pool, just like these virtual machines draw from the resources of the parent pool. And then finally, I could also give my resource pools a reservation. So I could say this production resource pool is guaranteed at all times to have a minimum of 16 gigs of memory, no matter what. That 16 gigs is permanently and consistently set aside for only that resource pool,and nothing else can use it. So I can dedicate a certain amount of physical memory strictly to a resource pool. And a VAP is very similar. A VAP is very similar to a resource pool. Again, it's a container that we can put multiple virtual machines in, and we can control shares, limits, reservations, and permissions. We can do all of those things that we just saw with a resource pool. However, the big difference between a VP and a resourcepool is that a VAP is largely intended for multitier applications in which we need to control boot order. So, for example, in this scenario, let's say that I've got this website that requires a database on the back end. So on the left hand side, we see my DB virtual machine, and then we've got an application server that kind of runs in the middle, and then we have the actual webserver that presents the web page to my end users. And so in this scenario, I know that for my application to work properly, the database virtual machine has to boot up first, and once it's ready to go, the app virtual machine can boot up. And then, finally and third, the web VM should boot. Last of all, you can control this boot order with the aVAP V app. It can be used to specify the boot order of the contained virtual machines so that you know that these three VMs will always boot in the correct order. Okay, so in this lesson, we learned how resource pools can be used to group together multiple virtual machines and provideresource pools like shares, limits, and reservations. We can also apply permissions and alarms at the resource pool level. Our ESXi host itself is referred to as the root resource pool. That's where the actual physical resources come from. And we can also even create a child resource pool within a resource pool.

10. Storage Virtualization

In this video, we'll learn about storage, virtualization, and how storage resources are presented to your virtual machines. So a virtual machine is similar to a physical one in many ways. It's got an operating system system installed on it, and in this particular case, it's got Windows installed on it, and it needs access to CPU, memory, and network storage. And the operating system does not know that it's running within a virtual machine. So our goal here is to basically trick the guest operating system into thinking that it has real hardware. So we'll provide access to memory,CPU, storage, and networking resources. And essentially, the goal here is to trick the virtual machine into thinking that these are just normal physical resources. So, from the perspective of the virtual machine and Windows, in this case, Windows needs to see drives. When I'm working in the Windows operating system, I'm saving a file or making some sort of change, those changes need to be written to a drive via a scuzzy command. And so, as far as the Windows operating system is concerned, it needs to see just regular old discs and a scuzzy controller, just like a physical Windows machine would see. So here on the far left, we see our little purple box. We've got a Windows VM. And the Windows virtual machine executes some sort of SCSI command. And we see here it's got a virtual SCSI controller. So Windows has drivers, and it appears to me like there's a physical hardware scuzzy controller. So when Windows has the SCSI command that needs to be written to the C drive, it'll send that scuzzy command to the scudsy controller. And if this were to be an aphysical system, the SCSI controller would communicate with the local physical disks. But this isn't a physical machine. This is a virtual machine. And so when those scuzzy commands are generated and sent to this virtual scuzzy controller, they're actually pumped into our hypervisor. And our hypervisor is what presents all the virtual hardware to our virtual machine. It's this layer of abstraction between the virtual machine and the actual hardware. And what it essentially does is decouple the virtual machine from the hardware. Here we see we have one storage adapter shown on the screen here, but there might be multiple storage adapters as well. And there might be multiple physical storage systems that they communicate with. None of this really matters to the virtual machine, right? The hypervisor can redirect those storage operations to different areas, but the virtual machine will never be any the wiser. It will have no idea where those storage commands are actually going. I don't know if this is a fibre channel storage rate. I don't know if this is I scusey.Windows has no awareness of any of that. So we're decoupling the physical storage from the virtual machine. All the virtual machine sees is a virtual scuzzycontroller and a C drive or D drive or whateverdrive it happens to be writing to. So the scuzzy commands flow out of the operating system through that virtual scuzzy controller, and the hypervisor takes over from there and directs them to the appropriate storage location. And the storage location in this case is a VMDK. That's a virtual disk. So for every C drive and D drive and every virtual disc that a VM has, it's backed by a VMDK file stored on a data store somewhere. So as those scuzzy commands get issued by Windows,this virtual machine has a VMDK file that the ESXi host is aware of and that the ESXi host knows where that VMDK file resides. And so those changes, those scuzzy commands, are going to be pumped over some sort of storage network towards that VMDK file. And in that manner, the changes made by the guest operating system are relayed to the virtual disc of that virtual machine. Now, when it comes to our VMDcase, we have a couple options. And let's say that we've created this Windows virtual machine,and when you're configuring your VM and setting it up,you can choose how big you want the virtual disc to be, and you can choose whether you want that virtual disc to be thin or thick provisioned. So let's assume that when we were creating our VM, we gave it an 80 gig virtual disk. But so far, we're only actually storing 40 gigabytes of data, right? So it's just like any other Windows machine. It might have an 80 gig disk, but Windows and whatever else we're storing on that disc might not add up to 80 gigs, and it might be less. So the actual data that's being stored by this VM is only 40 gigs worth, even though we've given it an 80 gig disk. If we're using a thin provisioned disk,that gives us some efficiency here, because there is 40 gigs of actual data. Well, that's the only space that will actually get consumed on the data store. So we don't immediately consume all of the space that's allocated to this VM on the data store. It's a much more efficient way to operate. If Windows only needs to store 40 gigabytes of data, that's all the space that will be consumed on the data store. And that's what a thin provisioned disc is. A thick provisioned disc is a little bit different. If I create an 80 gigabyte thick provisioned disc, it is immediately going to consume 80 gigabytes of space on the data store. So why would I ever go with a thick provisioned disk? Well, we now know that a provisioned disc saves space. It's very efficient. Whereas a thick provision disc allocates 100% of the space up front and before that space can be used, right, whether we're talking about thin or thickprovisioned disks, before any of the space can be used, the blocks that make up that space have to have zeros written to them, right? So if my virtual machine is about to write some new data to this VMDK and it's about to send some sort of new data here, the blocks that it's going to have to have all zeros written to them first, and this can take a little time,this is going to consume some storage resources, the actualprocess of writing out those zeros. So, if we're using a thin provisioned disk, none of those blocks are zeroed out when the disc is created. So every time we need to write to a new block on a thin provisioned disk, there's going to be a little bit of a delay there as that block is zeroed out. But thick provisioned discs have all zeros written up front when they're created. So they're not going to have to complete that zeroingoperation when new data is going to be written. So, for this reason, thick provisioned zero virtual discs are recommended for VMs with an intensive workload. Things like SQL virtual machines or SharePoint VMs. Okay, so in this lesson we learned that virtual machines are presented on virtual hardware and the guest OS is aware that it's running on a virtual machine. The guest OS just sees virtualised versions of hardware that it thinks are real. We learned that thin provisioned discs are space-efficient, but they don't have the same performance characteristics as a thick provisioned eager-zero disk. So those thin provision discs are useful in many situations, and their performance is fine in most situations. But if you have like a SQL database or SharePoint or an Exchange database availability group, those types of applications write a lot of new blocks and should be configured with thick provisioned eager zero.

ExamSnap's VMware 1V0-701 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, VMware 1V0-701 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.