06vcs6unixoperations Trans

23
Veritas Cluster Server 6.0 for UNIX: Install and Configure Lesson 5: VCS Operations

description

vc

Transcript of 06vcs6unixoperations Trans

  • Veritas Cluster Server 6.0 for UNIX: Install and Configure Lesson 5: VCS Operations

  • Lesson 1: High Availability ConceptsLesson 2: VCS Building BlocksLesson 3: Preparing a Site for VCS Lesson 4: Installing VCSLesson 5: VCS OperationsLesson 6: VCS Configuration MethodsLesson 7: Preparing Services for VCSLesson 8: Online ConfigurationLesson 9: Offline ConfigurationLesson 10: Configuring NotificationLesson 11: Handling Resource FaultsLesson 12: Intelligent Monitoring FrameworkLesson 12: Cluster CommunicationsLesson 14: Data Protection using SCSI 3 I/O FencingLesson 15: Coordination Point ServerLesson introduction

  • Lesson objectives

    TopicObjectivesCommon VCS tools and operationsPerform common cluster administrative operations.Service group operationsManage applications under control of VCS service groups.Resource operationsManage resources within VCS service groups.Using the VCS SimulatorUse the VCS Simulator to learn about VCS.

  • After completing this topic, you will be able to perform common cluster administrative operations.Common VCS tools and operations

  • VCS management toolsCLIVCS SimulatorCommand-line interfaceSuited for local cluster managementCreate, model, and test cluster configurationsCannot manage a running cluster configuration Java GUIDeprecatedOngoing support only for WindowsNeeded for using SimulatorVOMVeritas Operations ManagerSuited for large numbers of clusters Management for all Storage Foundation products

    http://go.symantec.com/vom/http://go.symantec.com/vcsm_download/

  • Displaying cluster statusDetermine the state of the cluster at a point in time:hastatus sumDisplay current status of all objects and subsequent configuration and state changes:hastatus

  • Displaying logsVCS log file location: /var/VRTSvcs/logHAD (engine) log: engine_A.logJava GUI command log:Is useful for learning the CLICan be used to create batch filesIs cleared when you log out of the GUIViewing log filesUNIX utilities:tail, pg, more, viewVCS hamsg utility: hamsg -help

  • Displaying object informationDisplay resource information:hares display resource hares list conditionhares value resource attrhares state resource Display service group information: hagrp display group hagrp list conditionhagrp value group attributehagrp state groupGetting HelpCommand-line syntax:ha_command helpman ha_commandBundled Agents Reference Guide

  • After completing this topic, you will be able to perform common VCS service group operations.Service group operations

  • Bringing service groups onlineService groups are brought online:Manually, after maintenanceAutomatically, when VCS is startedResources are brought online in order from bottom to top.Persistent resources do not affect service group state.

  • Taking service groups offlineService groups are taken offline:Manually, for maintenanceAutomatically, when VCS is stopped or during failover Resources are taken offline in order from top to bottom.A service group is offline when all nonpersistent resources are offline.webapachewebipwebnicwebmntwebvolwebdgwebsg

  • Switching service groupsYou can switch a service group betweensystems to:Test failoverMigrate services for maintenanceVCS:Takes resources offline on system S1.Brings resources online on system S2.Only resources online on system S1 are brought online on system S2.

  • Example: Switching websg

  • Freezing a service groupFreeze a service group to prevent offline, online, or failover actions even if a resource faults causing the group to fault.ExampleAdministrator can start and stop an application outside of VCS control

    PersistentRemains in effect through VCS restartsFrozen=1

    TemporaryOnly in effect until VCS restartsTFrozen=1

    When frozen, VCS does not take action on the service group even if you cause a concurrency violation by bringing the service online on another system outside of VCS.!

  • Application management practicesYou can mistakenly cause problems if you manipulate resources outside of VCS, such as forcing faults:Causing failover and downtimePreventing failoverUse VCS to start and stop the application.Direct VCS not to intervene:Freeze the service group.Perform administrative operations outside of VCS.Unfreeze the service group to re-enable VCS control.or!

  • After completing this topic, you will be able to perform common operations on resources in a service group.Resource operations

  • Bringing resources onlineResources are brought online:Automatically, when a service group is brought online Manually, after maintenanceIn dependency order from bottomAgent runs the online entry pointOnline entry point runs specific startup operationswebapachewebipwebnicwebmntwebvolwebdg

  • Taking resources offlineResources are taken offline:Automatically, when a service group is taken offline Manually, for maintenanceIn dependency order from topAgent runs the offline entry pointOffline entry point runs specific shutdown operationsdboracledbipdbnicdbmntdbvoldbdg

  • After completing this topic, you will be able to use the VCS Simulator to practice managing the cluster.Using the VCS Simulator

  • Using the VCS SimulatorThe VCS Simulator enables you to:Learn how to manage VCS using predefined clusters.Create and test new cluster configurations.Simulate faults to see how VCS responds.Use the Java GUI or the Simulator-specific command-line interface.Simulator software is:Downloadable from Symantec: Installable on Windows onlyPackaged with the Java GUIhttp://go.symantec.com/vcsm_download/

  • Simulator Java ConsoleUse the Simulator Java Console to:Start and stop sample Simulator configurations.Launch the Cluster Manager Java Console.Create new Simulator configurations.Verify configuration file syntax.Delete Simulator configurations.VCS Simulator online guide:https://sort.symantec.com/public/documents/sfha/5.1sp1/linux/ productguides/html/vcs_admin/ch08.htm

  • Lesson summaryKey points Use VCS tools to manage applications under VCS control.The VCS Simulator can be used to practice managing resources and service groups.Reference materialsSORT downloads:http://go.symantec.com/vcsm_download/http://go.symantec.com/vom/Symantec Connect: symantec.com/connectVeritas Cluster Server Release NotesVeritas Cluster Server Users Guide

  • End of Presentation

    Transcript: BRAD WILLER: Welcome to VCS 6.0: Install and Configure, VCS Operations. Author's Original Notes:

    Transcript: This is lesson number 5 of 15. Author's Original Notes: This course contains 15 lessons.

    Transcript: In this lesson, we're going to look at the different tools we have to administer VCS, we're going to look at some typical things you do with service groups, we're going to look at some of the typical things you do with resources, and then we're going to briefly talk about the VCS Simulator. Author's Original Notes:

    Transcript: The first lesson, first topic is VCS tools and operations. Author's Original Notes:

    Transcript: So as we've briefly talked about before, there's really two primary ways that you can manage and administer your environment. But there's a couple of other tools as well, so that's where all four come in. First and foremost is command line. As I mentioned, you always can manage locally and so typically you'll do everything with the command line. Well, one of the things we'll see is that typically the commands start with HA. Then you also can use VOM. In the last lesson we looked at how to install VOM, how to make the systems a managed host. So same deal here is the benefit of VOM is the scalability. So if I've got 100 clusters out there, boom, I can use VOM to see all 100 of those clusters. You also can use the VCS Java GUI. Now, as I mentioned, it's no longer specifically part of the product. You actually have to go get it and download it. Down at the bottom of the slide is the URL and what you'll notice on that is it actually -- when you go there, you'll find out that the VCS Java GUI, the Storage Foundation Java GUI, which is called VEA, and the VCS Simulator are all bundled in one packet. So you'll actually download all of them and then you can install the ones you want to. The VCS Simulator is a really cool tool that you could use to do testing, do what-if scenarios to learn about how VCS works. You actually could also use it to modify an existing configuration. The beauty of it though is it's not a live cluster. You're -- it's actually running typically on your laptop. It's only for Windows. So you'd have to be running on a Windows PC or in a VM, but the beauty of it, again, is that it will utilize the Java GUI and you can see that it looks exactly like a production environment. So, in fact, one of the best things is to download your own environment from one of your clusters and take a look at that. So again, we'll talk about that briefly in a little more detail. Author's Original Notes:

    Transcript: All right, probably the most common command from a VCS perspective is hastatus. That's -- when you're doing troubleshooting that's probably your number one command. Now there's a couple of ways to do this. My personal favorite is to do an hastatus -sum. We saw that in the previous lesson and, again, sum is short for summary and it just gives you the core details of here's what's up. Here's all your systems in the cluster, what their state is, here's all your service groups, what's their states. And then if anything is out of whack, something has failed, etc., things like that, it points it out. So you get down to the brass tacks of what you need to know. Then there's also hastatus by itself. What hastatus by itself does is it reports everything. So it shows the state of every single system, service group, resource and then it just sits there and only reports when a state change has occurred. Now there's an actual attribute for everything, for the cluster, for systems, for service groups, for resources called STATE and that is basically what it's reporting. There's also -- for resources, for example, there's a state called ISTATE or internal state and it actually reports that too, but a state is something like online, offline, faulted, etc. And so the whole idea of hastatus is to just report that state and only report something when it's changed. So some customers really like that as well. Author's Original Notes:

    Transcript: As I mentioned before, the log files are critical here and the key directory, again, is shown there. It's one of the two most critical directories as far as VCS goes and that's /var/VRTSvcs/log. In there, HADs -- remember, HAD is the engine, the VCS engine, hence the reason the log is called the engine log. It's engine_A.log and you'll actually see that the agents have logs in there as well. So for example, it would be mount_A.log, diskgroup_A.log, etc. You may see other log files that have B, C or D. What happens is when a certain amount of information has been written to a log file and there's actually an attribute that says how large to let the log file get, what it'll do is it'll kick over to a new log file. So the current log file, i.e., the one you want to look at from a troubleshooting perspective, is always the A log. So what happens is if -- and the default is actually 32 Meg. So let's say that HAD is going to write something to engine log that's going to be more than 32 Meg. What would happen is HAD would basically do a ripple effect, is the current A log would get renamed to B. If there was a B -- of course, it would do this from the bottom-up, but I'm going to go from A down. A would become B, B would become C, C would become D and if there was a D, it would actually get deleted and then, of course, a new A would be created and the information would get written to A. So we just ripple the log files down. We keep up to four of them. The only log file that I've personally ever seen that's had other than an A is the engine log and, again, that's because so much information gets written to that log file. As I mentioned, I would estimate probably 90% of the VCS issues can get solved by actually taking a look at the engine log. There may be cases where the other log files have more than an A. Again, it all depends on the amount of data that gets written to it, but typically the agent log files are much, much smaller in size versus the engine log. If you use the VCS Java GUI there actually is what's referred to as a command log. That's a memory-only log though and it keeps track of the things that were done while you were in the VCS Java GUI. And basically what it does is when you do something in VCS, in the Java GUI, you know, you click this button, you click that button, that's going to end up causing something to happen. Well, what the command log shows you is the corresponding command line that would be executed to do what you just did in the GUI. So it's a really nice way to see kind of under the covers what actually just happened and if I did have to do it from the command line, what would I do. Author's Original Notes:

    Transcript: Probably the most important thing I think from a VCS perspective is being able to get information. As I've mentioned previously, everything has attributes and, again, I liken attributes to variables. So there are cluster-level attributes, system-level attributes, service group-level attributes, resource-level attributes, etc.. And so, consequently, there are HA commands to see that information. Because what you're basically going to be doing is you either need to see what information is currently there and/or modify that information. If you remember, I was talking about how if I had a mount resource, I had to tell VCS the appropriate thing so that VCS could mount up that file system, i.e., online that resource. So I would have to say things like what's the block device, what's the local mount point, what type of file system it is, etc. That's all information that gets put into the corresponding attributes for that resource. So a very important thing, one of the most important is how do I see that information. What I'm going to describe for you is basically we're going to go from the broadest information down to the most specific information. The command where you see the broadest amount of information is the ha whatever -display. So you'll notice this slide focuses on resources and service groups, and so the resources command is hares, the service groups is hagrp but the same thing. There's a cluster, haclus, there's system which is hasys. All of them have a -display. By default that shows you every single attribute. So in fact, on this slide, you'll notice, for example, it says hares -display resource. In almost every situation on this slide, the part that's in italics should actually be in square brackets because it's optional. So what that means is if I were to type hares -display, again, this is going to give me the broadest information. So you typically always are going to pipe that to more because what that would do is it would give me every single attribute for every single resource in the cluster. It doesn't matter how many service groups, it shows me everything. If I wanted to see a specific resource, I would do hares -display and then the name of the resource. So now, it would match what was on the slide and then that would show me every single attribute for that one resource. So you can go that route. Remember I mentioned that one of the nice things to do from a naming convention is to have a string of characters that's the same for all resources in a particular service group? So for example, I could do an hares -display and then grep, pipe that to grep -i web, and now that would show me every single attribute for anything that has web in its name, so basically, all of the attributes for the resources that were web something. And that's the kind of thing you'll do initially, you're not sure what you're looking for, so you go ha whatever -display and you pipe it to more and you start to look through things or you grep. And as I mentioned, make sure you do a grep -i because then you don't have to worry about the uppercase/lowercase thing, ignore the case, and you start to focus in on what you're looking for. That's one of the ways to do that. Another thing you can do that kind of narrows it down a little bit is the hares -list, the -list option, you know, hares -list or hagrp -list. If you go hares -list by itself nothing after it, it'll actually show you the names of every single resource in their corresponding service groups. So that's a really nice way to figure out what you've got out there. If you're not sure what the names of your resources are, boom, hares -list, there you go. hagrp -list, same thing. It shows you what service group names you have out there on what particular systems. You'll notice it says hares -list and the condition. If you do that, that's really nice because remember the different attributes have values. For example, one of the very important attributes that every resource has regardless of its type is called Critical. Critical in a nutshell tells VCS whether failover needs to happen or not. So Critical has two values, one and zero. If the attribute is turned on, i.e., the resource is marked as critical, it's set to one. If the resource is considered non-critical, that value is set to zero. So for example, you might say hares -list Critical=0 and then that would list out for you every single resource that is non-critical, i.e., where the Critical attribute is set to the value of zero. So again, here I can start to really narrow things down. So I can do that from my resources and I can do that from my service groups and, again, any attribute can be used there. Then if I want to look at the most specific, that's the hares -value. That's the only one on there -- and hagrp -value, of course, as well. Those are the only two on there where you have to give the other information. You have to say the name of a resource, you have to say the name of an attribute, or you have to say the name of a service group, have to say the name of an attribute because what that returns is a very specific, just that information for just that one attribute. So for example, if I said hares -value Critical (space) webmnt then that would tell me that specifically for -- oh, sorry, I said that backwards I think, hares -value webmnt (space) Critical. That would tell me specifically what the value of Critical was for the resource webmnt. And what's really nice about that is it just returns the value. Whereas I actually could do a similar thing with hares -display, but I'd get other information with it like the name of the resource, the name of the attribute. Here it would just return the zero, for example. And so, what's nice about that is it's very explicit, as well as I could use that in say a shell script. That could be input to a command in a shell script. I could have an if statement, for example, and if the value is zero then go do this, if the value is one go do that. So very, very specific, so the -display, very broad, -value, very specific. The last one you'll notice is -state. For hares and hagrp especially, but also for hasys and actually for the cluster, but system, resource, service group tend to be the more typical ones. The -state actually specifies the value for the state attribute. There actually is an attribute called State with an uppercase S. So that will tell you what's up with that resource and again, if I just say hares -state, it shows me the attribute -- it tells me the value for every single resource, which is more or less what hastatus by itself does. If I do hares -state webmnt, for example, that shows me what the state of that resource is on every single system that that service group can run on. So on System 1, for example, it's offline, on System 2, for example, it's online, that type of idea. Okay, so what I would really encourage you to do as you're getting used to using VCS is start out with the ha whatever -display and pipe it to more. And as you start to see what information is out there and you start to get more familiar then you start to narrow it down as you need to. To get help on this, of course, there's the MAN pages. That's why we wanted you to add /opt/VRTS/man into your MANPATH variable and then there's also each command has a -help option to it. So, for example, I could say hares -help and what that's going to do is that gives me quick syntax so that you'll see a lot. In fact, if you are even as remotely as bad a typist as I am, you will see the hares -help an absolute lot because what happens is if you type something in and you do it incorrectly, VCS will yell at you, give you an error message and then dump out the help. So you'll see the quick syntax a lot. Don't forget the Bundled Agents Reference Guide, all of the agents that come standard and then there are also going to be Install and Config Guides for the other agents like the database agents. Author's Original Notes:

    Transcript: So that's how you get information. Now, the next thing we're going to look at is what are some of the operations you can do with service groups. These are all things you're going to end up doing in more detail throughout the week, especially if you do the labs, but we wanted to look at and to start with the week. Author's Original Notes: This is , .As a reminder, the objective(s) for this topic is/are: .

    Transcript: All right, with a service group, you can online the service group. Now remember, service group is your application. So you'd do an hagrp -online and then you'll say the name of the service group and then typically you'll say what system to bring it up on. When you do that, we start at the bottom and work our way to the top. So we start at the bottom resources and go all the way to the top resources. The way we do that is we actually start with every branch of the tree simultaneously. This is why those dependences, those links are so important. It tells VCS exactly how to bring things up. Excuse me, in this particular example, on the slide, you'll notice there's really two branches. So the bottom resources are webdg and webnic. So both of those resources come online first. webnic, if you remember, is an example of a persistent resource. It's always there. So that guy's already online. So VCS will go ahead -- so the state is online, VCS is happy with that. Now, it'll move to the next guy. So at the same time that webdg is coming up, in reality, webip is going to start being brought up. Let's say that webdg is still coming up because for some reason it's taking a while and now webip is online. Now VCS would naturally move to the next one called webapache. But if you notice, webapache actually has two dependencies. So webapache cannot come online until both of its dependencies are there. So webip is there, but at this point in my example webmnt is not. So that guy has to wait. Now webdg comes online, then webvol comes online. Now webmnt comes online. Now both webmnt and webip are online so now webapache can come online. So if you'll notice from that simple example, that's why the dependencies are so critical, because you tell VCS exactly how to bring things up and a resource cannot come online until the things below it are online. The other thing I just want to point out is I mentioned that we'll start all branches of the tree. Your service group does not have to look nicely and end in a top resource like that. It can look however you want it to. It all depends on what the thing needs. So for example, let's say in this particular application there was some other part of it that maybe had to set a cron job. So completely independent of everything else, it had to do this cron job part. So you actually could have another branch of the tree that say was two resources linked together, completely independent of everything else. So in that example, if that was the case, then VCS would actually be starting three things up simultaneously and that one little standalone of two might be completely finished before everything else comes up. So the dependencies tell it exactly how to bring things up and we'll see in a second, conversely, how to take things down. Author's Original Notes:

    Transcript: Here's the offline. So we do an hagrp -offline. This takes things down. We start at the top and work our way to the bottom, so the exact opposite of what I just described. So webapache goes down first. Now that it went down, we can go down both branches of the tree. So webip would go down, at the same time webmnt would start to go down. Let's say webip is finished. Now the next one you'll notice is webnic. Remember webnic was a persistent resource, we don't take those down. So we're actually finished with that branch of the tree. That's why you'll notice that in this slide, the resources are grayed out, that's showing offline, whereas something that's blue is showing online. So when this is all said and done, this service group is offline, but the NIC resource is still online because a persistent resource we don't take down. It isn't considered part of the equation when we offline a service group. Because remember, in this example, webnic is the public network. If we were to take the public network down that would affect other things outside of VCS. Author's Original Notes:

    Transcript: We can also switch a service group. Switching a service group is a combination of offlining and onlining. So when we do an hagrp -switch what we're basically doing is that's referred to as a manual failover. So for some reason, the application is running on this node and you want it to move over to this node. That's an hagrp -switch. So it has to completely come down here, i.e., offline, then and only then can it come online over here. Obviously, you could do exactly the same thing with doing an hagrp -offline and then doing an hagrp -online to get it over here. It's just a simplified way of doing both of those. So again, that's referred to as a manual failover. Author's Original Notes:

    Transcript: Here's just an example of some logs showing -- like this is showing the engine logs, seeing all the different information when you switch a service group. So you'll see that each individual resource is logged as coming down in the appropriate order and then it's also showing you a little bit of the hastatus output where you can see the state of different resources is changing. So if you were to follow along as you actually did this, this is the kind of thing you would see in the engine log as well as in hastatus. The engine log, as I mentioned, has an absolute wealth of information. So in fact, one of the things I would really encourage you to do is as you're doing things in VCS, especially as you're learning, is do a tail on that log file, have a separate terminal window open and do a tail -f on /var/VRTSvcs/log/engine_A.log and just let that go. So as you do something, you'll see all of this stuff happening in the engine log. So, it's a great way to be able to figure out exactly what's happening which is exactly why I mentioned that at least 90% of the issues can be solved by looking at that log. Author's Original Notes: screenshots to be updatedTranscript: The next topic is freezing and this is actually a really important topic to understand. What freezing is is if there's ever a time when you need to do something outside of VCS, you freeze the service group. The thing you have to remember is VCS is a high availability cluster. So the whole purpose is to make sure your applications are highly available. So if something goes wrong to your database on one node the whole idea of VCS is to fail that thing over to another node to get you back up. So if you need to do some kind of management to your application outside of VCS, so the DBAs are working on the database or you're mucking with files within the file system or something that's really going to change, potentially change what's up with the application, very, very important that you want to freeze VCS first. What freezing tells VCS is basically back off, don't do anything. Report, but don't do anything. So the situation is this. Let's stay with the idea of the database and the DBAs need to take the database down to do some kind of maintenance and they don't tell you guys, they don't tell the sys admins, they don't do anything in VCS, they just take the database down. What happens is VCS is constantly monitoring it because let's assume that's an application that's under VCS control. VCS is constantly monitoring that just like if the database actually crashed, you would want VCS to monitor that. So the DBA takes the database down, VCS reacts to that, takes the entire application down, fails it over to another node, brings it up on the other side because if there was a problem that's exactly what you would want VCS to do. In this particular case that's not what you wanted to have happen because the DBA really needed it to stay over here to do some work on it. Well, that's what VCS did automatically. So to make sure that doesn't happen, you freeze VCS. So again, that tells VCS to back up. You can report all you want, but don't do any failover. So what that really boils down to is you can't do onlining, offlining or failover within VCS. So now, if the service group was frozen, VCS -- and then now the DBA takes the database down, VCS would react to that. And so, the database resource and the service group would go into a faulted state, but since the service group is frozen, no failover would occur. So now, the DBA could go about, do their work, do everything they need to. When they're finished, they bring the database back up, the next time VCS monitors, it sees the database as back up and now it goes ahead and clears the faults and says everything's okay. So it'll still monitor, but that's it. So the rule of thumb is if you ever have to do anything outside of VCS, freeze the service group first. You actually can freeze a system as well. So for example, let's say I had a three-node cluster and I needed to pull one node out because I was doing a rolling upgrade or I was patching that system or whatever I was doing. Same exact concept, you would freeze the system first. So now, VCS won't use that system, i.e., say an application was running here, it would not failover to that system. So you freeze the system, now you can take the system down, patch it, do whatever you want, you know, reboot it to your heart's content. When you're finished, it joins back in, but now you unfreeze it and now things will work as normal. Same thing with a service group, when you're all said and done, you would unfreeze it and now normal failover, starting, stopping, etc., can happen. There's two types of freezes. There's a temporary freeze and a persistent freeze. The concept is exactly the same. The concept is if I need to do something to the app outside of VCS I freeze it. What's different between the two is for a temporary freeze, you don't need the same level of permissions that you need with a persistent freeze. We're going to talk about different levels of permissions you can do within VCS. Temporary only requires what's referred to as operator capability versus admin capability. So it needs a lower level of permissions. The other difference is it's not persistent. So if the entire cluster went down, when you brought the cluster back up, the service group would no longer be frozen. For persistent, it's the opposite basically. Again, they do exactly the same thing from a VCS doesn't failover perspective but to do a persistent freeze, you're actually modifying the configuration. So you need admin level permissions to do that and it's persistent in that if the entire cluster goes down, when the cluster comes back up, that service group would still be frozen. To do that, there's a little more involved, which we'll talk about later on how you actually make changes. You have to do what's called open your config, make your changes, close your config so that the changes actually get written to disk versus just being in memory but that's a topic for a little later. Right now, I just want to make sure you understand the difference between what freezing is in general and then the difference between temporary and persistent. What usually it boils down to is if as sys admins you want to allow your DBAs, for example, since I've been doing a database example, to be able to freeze their service group, you would usually set them up with operator capability. If you wanted to do it, you as a sys admin typically have admin capability and so the DBAs would typically do a temporary freeze, you would typically do a persistent freeze. But again, it really is up to you and if the entire cluster goes down and comes back, do you want it frozen or not, that's really what it boils down to. Author's Original Notes:

    Transcript: Okay, we've pretty much talked about this in the last slide is that if you need to bring something up and down, you could actually use VCS you could do the hagrp -offline, hagrp -online that we just talked about or you could do the freezing and then outside of VCS you bring things down and up. It's completely up to you what makes the most sense. The key thing though, if you're going to do anything outside of VCS, like I said, make sure you freeze the service group first. Author's Original Notes:

    Transcript: So that was some of the service group level operations. Now we're going to look at some of the resource level operations, same basic idea. Author's Original Notes: This is , .As a reminder, the objective(s) for this topic is/are: .

    Transcript: First is online, exactly the same idea as service group. The difference is it's an individual resource. When I onlined my service group, I brought everything up. If I online a resource, I'm bringing up just that resource. Not as common to do. It's much more common to do the entire service group. Usually the time you would do this is at least when you're first setting up a resource because you're adding everything in, you're making changes and now you want to validate the thing can actually come up. That's probably the most common time to do it. The other time you might do it is during troubleshooting in that something went down you're trying to fix it and now you want to validate that VCS can bring it up and maybe take it down. All right, just like we talked about with service groups, when you online resources, again, you start at the bottom and work your way to the top. So in this particular example, you'll notice that we do an hares -online and then you say the name of the resource and then you say where you want to bring it up. So in this example, we brought up webdg because notice it's blue. So it's online, everything else is offline. Then I would do webvol the same way, then webmnt. So I could step through each one of these. Again, when you're doing troubleshooting and testing that's exactly what you'd do. If -- let's say there was some issue and webdg was the problem, so now you've solved the problem. At this point, you'd probably say, you know, I just want everything else to come up. So at that point, you'd probably do an hagrp -online and let VCS automatically bring the rest of them up. It's completely up to you. The other thing that's key is what are the states. Remember, a state of a resource and service group, the primary states are going to be online or offline and then faulted if something went wrong. So, in this case as well. Right now, before I did that hares -online, the state of every single resource except webnic was offline. Now I did the hares -online of webdg. Now the state of that resource is online. So I've got two resources online and four resources offline. From a service group perspective, what happens is the service group before webdg would be completely down, so the service group would have been offline. As soon as I onlined one resource, now the service group would change from offline to what's call partial. Partial online means that something is up, but there's other things that aren't up yet and we don't take non-persistent resources into the mix here, you know, so webnic, for example. So basically what would happen is if I manually onlined each resource, so now I bring up webvol, the state of the service group is still partial. I bring up webmnt, still partial. I bring up webip, still partial. As soon as I bring up webapache, which is the last of the resources, once that guy's online, now the state of the service group goes from partial to online. So as things come up, it goes from offline to partial until everything is up, then it goes to online and the same thing in the next slide where we start to bring things down. Author's Original Notes:

    Transcript: As soon as I take one guy down, the service group goes from online to partial. It's not till I take the last guy down that it goes from partial to offline. And so, the idea of hagrp -offline is exactly the same, is the opposite, of course, of hagrp -- hares, excuse me, -online is I'm one-by-one taking things down. And again, typically, you do that for some type of testing. You don't tend to do it a lot once everything's up and running. Author's Original Notes:

    Transcript: All right, the last thing we're going to talk about is a little bit about the VCS Simulator. Author's Original Notes: This is , .As a reminder, the objective(s) for this topic is/are: .

    Transcript: The Simulator is a really cool tool that allows you to basically try things out, do what-if scenarios, try a new configuration, test out a new feature, learn about VCS, really anything you want. There actually is a command line associated with it, not so common to use because the command line is a little different from the actual command line. So most customers that use the Simulator tend to use it with the VCS Java GUI. The Java GUI looks almost exactly identical between what the Java GUI would look like if you were actually connected to a production environment, at the same time you -- if you compared that versus connecting into a Simulator, but the key difference on the Simulator is everything is running on your laptop. So nothing really exists. And so, in fact, there's a simulator running on a different TCP/IP port on your laptop that simulates being HAD and it simulates all the agents. So it's just local, but how things react from a VCS perspective are the same. It's quite cool in that respect. There's the URL again, how you can download it. When you do -- as I mentioned, when you go there, you'll see that the Simulator, the VCS Java GUI, and actually the VEA Java GUI are all bundled together. You don't have to install all of those, but if you do install the Simulator, you automatically get the Java GUI, VCS Java GUI. If you install the VCS Java GUI though, you don't get the VCS Simulator. So most customers install the VCS Simulator and then they've got both the Java GUI and the Simulator. Author's Original Notes:

    Transcript: Here's a little bit of what the Simulator looks like. One of the nice things is you actually get some canned configurations as part of the Simulator. So you'll see that there's -- and the way you read that is you'll notice it says Linux NFS, for example, or Solaris, etc. So it tells you what platform, but you can also see to the far right what platform it is. So even though this is only running on Windows, you actually can have configurations loaded in for all the other platforms. When you set it up you'll -- part of setting it up will explicitly say what platform does it run on, you know, is it from, for example. Down at the bottom is a really good doc, you want to go get a look at that. That will help you through because we don't really spend much time with the Simulator any more since it's kind of decoupled from the product. But that's a doc that's been written and although it says 5.1 SP1 and it's Linux, that's okay. It's telling you key information on how to set things up with the simulator. And as I mentioned, one of the I think absolute best features of the Simulator is you actually can take your files, your configuration files from a production environment, put them on your laptop and load that production environment into the Simulator. One thing I would caution you when you're doing this is I've found because I tend to be fairly conservative is make sure you're not actually connected to a production environment when you do that. What I mean is don't have the Simulator running and the Java GUI connected to a production environment at the same time. It's too easy to confuse them. When you look closely, when you're running the Java GUI, it will tell you that you're connected to a Simulator versus connected to a production environment, but it's a title bar thing and outside of that, they'll look identical. So, it's very easy, I think, to accidentally be doing stuff to the production environment when you're really thinking you're doing it to the Simulator. So play it safe, don't be connected. You know, download those files, exit out of any windows or whatever that are connected to your production environment then deal with the Simulator. Author's Original Notes:

    Transcript: All right, so that was a little bit about how we do various things with VCS and in coming lessons we'll get into those in much more detail. Author's Original Notes:

    Transcript: End of Presentation Author's Original Notes: