SolarWinds Technical Reference

Transcription

1 SlarWinds Technical Reference Using Orin Grups and Dependencies Intrductin The Need t Manage Netwrks t Meet Business Gals... 3 Orin Service Grups (Grups)... 3 Nested Grups... 4 Grup Status... 5 Dependencies... 9 Alerting and Reprting This Technical Reference demnstrates hw grups and dependencies are created and prvides implementatin examples. netwrk management simplified - slarwinds.cm

2 2 Using Orin Grups and Dependencies Cpyright SlarWinds. All rights reserved wrldwide. N part f this dcument may be reprduced by any means nr mdified, decmpiled, disassembled, published r distributed, in whle r in part, r translated t any electrnic medium r ther means withut the written cnsent f SlarWinds. All right, title and interest in and t the sftware and dcumentatin are and shall remain the exclusive prperty f SlarWinds and its licensrs. SlarWinds Orin, SlarWinds Cirrus, and SlarWinds Tlset are trademarks f SlarWinds and SlarWinds.net and the SlarWinds lg are registered trademarks f SlarWinds All ther trademarks cntained in this dcument and in the Sftware are the prperty f their respective wners. SOLARWINDS DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SOLARWINDS, ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF SOLARWINDS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Micrsft and Windws 2000 are either registered trademarks r trademarks f Micrsft Crpratin in the United States and/r ther cuntries. Graph Layut Tlkit and Graph Editr Tlkit Tm Sawyer Sftware, Oakland, Califrnia. All Rights Reserved. Prtins Cpyright CmpnentOne, LLC All Rights Reserved. Dcument Revised: 04/11/2011

3 Using Orin Grups and Dependencies 3 Intrductin The Need t Manage Netwrks t Meet Business Gals This paper will demnstrate hw Service Grups and related features can be used in SlarWinds Orin prducts t simplify netwrk and systems management. The reader shuld be familiar with SlarWinds Netwrk Perfrmance Mnitr (NPM), Applicatin Perfrmance Mnitr (APM), IP SLA Manager (IP SLA Manager), and the use f the Settings sectin f the Web Cnsle. At the mst basic level, Netwrk management invlves mnitring netwrk assets fr metrics such as perfrmance, availability, resurce usage, cnfiguratin, and apprpriate usage. Fr the smallest f netwrks, this level f management wrks well. As a netwrk grws in size and cmplexity, new management needs arise. Perhaps a small netwrk riginally designed t supprt and web access is nw being used t sell items n the Internet. Custmer-rder web servers are added alng with client, inventry, pricing, and fulfillment databases. As this business grws, new systems are added and the cmplexity f the netwrk increases. When a netwrk issue ccurs, it culd affect any prtin r functin f the netwrk. Fr example, let s say a custmer submits a large rder, but the fulfillment database has a full drive and cannt accept the rder. The custmer receives an errr message after filling ut tw pages f rder and billing infrmatin, abandns the site and buys elsewhere. The persn managing this system may ntice that a drive has n available free space, and replace the drive with a larger ne. Between the first failed custmer rder and the placement f the new drive, there was sme unknwn number f failed rders and custmers wh abandned the site. There are tw glaring issues in the scenari. First, the persn managing the system is nly applying break/fix management and has n insight int issues befre smething breaks. Secndly, this persn has n insight int hw these individual machines are wrking tgether t supprt the business prcess. By adding a simple Netwrk Management System (NMS), the netwrk manager is able t see prblems develp befre they becme utages and quickly determine what part f this simple netwrk needs attentin. As this enterprise cntinues t grw, each system becmes mre cmplex and mre reliant n ther systems. While the NMS implemented can scale well, it des nt have the ability t manage the netwrk in a way that is cngruent with business prcesses and business gals. In this cmplex netwrk envirnment cmplex dependencies exist where individual systems and grups f systems are reliant n ther systems r grups. Managing the netwrk as a cllectin f separate entities is n lnger sufficient. Orin Service Grups (Grups) SlarWinds has intrduced service grups t address the need t assciate managed bjects. Grup bjects can be physical items such interfaces and ndes as well as lgical bjects such as applicatin perfrmance metrics r IP SLA test results. Tw types f service grups can be created: static grups and dynamic grups. In static grups, all grup members are manually added and the grup members are nly edited by manual means. In dynamic grups, the members are specified by indicating a requirement, s that any managed bject that meets the requirement is added t the grup. Qualifying new bjects added after the grup has been established will als be autmatically added t the grup. Likewise, bjects which n lnger meet the grup membership are autmatically remved frm the grup. This may ccur if yu edit the grup requirements, r edit the prperties f a grup member.

4 4 Using Orin Grups and Dependencies Nested Grups Grups can cntain grups as members. These are called nested subgrups. Creating grups with nested subgrups can be a cmplicated task if nt prperly planned. Planning and sme insight int the behavir f the Manage Grups interface can help speed the creatin f grups and minimize trubleshting. Fr example, let s say I want t add all devices in a remte site called building 7, but I als want t grup these devices by flr. I culd create a grup fr bldg 7 and assign all devices in bldg 7 t the grup, perhaps by using a dynamic query returning the Lcatin field. This will add all managed ndes that have the Lcatin in their cnfig set t Bldg 7. The lcatin OID in MIB2 is a field Orin autmatically plls and stres fr all managed bjects. This will wrk if all f the managed ndes in building 7 have exactly the same OID value f Bldg 7. If sme were added with Build 7 r Bld 7 r a number f ther nnstandard lcatin indicatrs, they will be mitted. While dynamic queries can be a pwerful methd f managing grup membership, they can cause great truble if misapplied. Let s examine sme mre infrmatin abut building 7. We find in the IP scheme that building 7 was designed t have ne 10.7.X /24 subnet fr each f its flrs. The first flr is /24, the secnd is /24 and the third is /24. This IP scheme is enfrced in the ruting prtcl and by ACLs. With this infrmatin we can create the grups fr building 7 and all the subgrups quite easily. Here are the steps: 1. Create an empty grup called Bldg With the Bldg 7 grup checked add a grup called Bldg 7 1 st flr. 3. Create a dynamic query fr the Bldg 7 1 st flr using IP Address begins with (Be sure t use the trailing dt, therwise the query is equally valid fr.10 and.100, which are nt valid first flr systems accrding t ur schema) 4. Repeat steps 2 and 3 fr all ther flrs, changing the grup name and IP address query t match the flr number.

5 Using Orin Grups and Dependencies 5 Once all the abve steps are cmpleted, we have created a grup fr building 7 cntaining a subgrup fr each flr. There is n need t add each individual nde directly t the Bldg 7 grup as they are all members f Bldg 7 by being members f ne f the subgrups. This can be helpful in minimizing duplicate alerts and duplicate reprt entities and saves the time that wuld be used t add items t the Bldg 7 grup and then t the prper subgrup. Grup Status When a grup is created, yu can set the status rllup mde fr the grup. The rllup mdes allw yu t make chices n hw the grups status will be determined, using the status f the grup members. The chices are Best status, Wrst status and Mixed status. Best status shws the grup status the same as the best status f any grup member(s), disregarding the status f all ther members. Wrst status shws the grup status as the wrst status f any member(s), again disregarding the status f all ther members. Mixed status will shw the grup as a single status when all members are in that particular status and warning when there are members with different status. Here are sme cnclusins yu can make accrding t the status rllup yu chse. Fr Best status rllup: If the grup status is Critical, all members are in the critical state. If the grup s status is anything ther than Critical, at least ne member is in the displayed state. N members are better than the displayed status. It is als pssible that all members are in this state. Fr Wrst status rllup: If the grup status is Up, all members are in the Up state. If the grup s status is anything ther than Up, at least ne member is in the displayed state. N members are wrse than the displayed status.. It is als pssible that all members are in this state. Fr Mixed status rllup: If all members are in the same status, that status will be the grup status. If the grup status is warning, either the grup cntain items f differing status (mst cmmn), r all members have the status f Warning (uncmmn). While this may seem cmplicated, the lgic fr chsing which type f rllup is fairly straight frward. Fr a grup where every direct member (nt member f a subgrup) is critical t be in the Up state, chse Wrst status rllup. This will ensure that if any member has an issue, yu will see that reflected in the grup status and any alerts r reprts created fr that grup. Fr grups with redundant member resurces, such a dual attached WAN, chse Mixed r Wrst status rllup, depending n the criticality f a wrst-case, single-member failure.

6 6 Using Orin Grups and Dependencies Fr grups with a high level f redundancy thrughut all direct members, chse best status. The reasn why we specify direct members and subgrup members is t allw fr the grup status rllup t be an additive rllup, frm the lwest level subgrup t the tp-level grup. Take the fllwing datacenter (DC1) fr example. Let s create ne tp-level grup called DC1 and then create member subgrups fr all the like items. The chices are many. We culd create grups fr each redundant server pair r a grup fr all redundant server pairs. The nn-redundant servers culd exist as individual bjects r as ne r mre grups. T make a plan n hw t arrange these, we will first cnsider ur gal; t manage the data center netwrk. This means that at this time we are nt cncerned with the prcesses that are enabled by the netwrk, just that the netwrk is available and perfrming well. In examining the naming cnventins fr the data center switches we find that they have well planned and cnsistent device names as fllws: All cre switches are named DC1-cre-xx, where xx is the cre switch number. All service switches are named DC1-service-xx, where xx is the service switch number. All distributin switches are named DC1-dist-xx, where xx is the distributin switch number. With this in mind we create the three dynamic service grups fr the abve items.

7 Using Orin Grups and Dependencies 7 Dynamic service grup DC1 Cre where a query fr system name cntains DC1-cre. Likewise grups are made fr the service switches and distributin switches. Nw we ll lk at the servers. In speaking with the server wners, they state that they dn t care if a server is redundant r nt. If a server is having a prblem, they want t be able t see that frm all levels. With this infrmatin we set the servers sub grups t all shw wrst member status as grup status. We find we can add the redundant servers using a dynamic query, but unfrtunately we are unable t identify any cmmn and unique qualifiers fr the nn-redundant servers, s these servers will be added statically, as individual members f a DC1- nnredundant-servers subgrup f DC1. The nly items left are the switch prts and links t the crprate netwrk. These have gd cnsistent prt descriptins which allw us t create prt and prt type grups. Seeing this, we create dynamic grups fr the crprate netwrk prts, the cre prts, and the distributin prts. By lking at all the netwrk equipment, heavy use f cnnectin redundancy, we take the same path as the server teams and set the subgrups status in each case t reflect the wrst member status. Then we als set the status f the DC1 grup t the status f the wrst member. Here we have taken the mst cnservative apprach t managing the grup status. When any bject in any f these grups fails r slws enugh t trigger a threshld, we will see that status reflected as the status f DC1. But is this a wise idea? While we d want t quickly find and identify the failed element in DC1, having the grup status set t the wrst status will prbably indicate that DC-1 status in Up (green) r the DC-1 status is Dwn (red), Warning (yellw) when in all three f these pssible cases DC-1 as a whle is perfectly peratinal. A better chice wuld be t keep the subgrups as Wrst status and set the status f DC-1 t Mixed. In s ding, DC-1 will be green when every element f the grup is Up and will have a warning status if there are elements with a status lwer that Up. Perhaps the wrst chice wuld be t set the DC- 1 grup status t Best. If we did this, DC-1 wuld always have an Up status, even if every member but nly ne has failed. Here, we have created ne tp-level grup and ten subgrups, all at the secnd level. Yu can chse t embed subgrups as far as yu want int ther subgrups. There is n hard limit, but as yu embed grups deeper, the lgic becmes mre cmplex. Objects can als be members f multiple grups. Implementing reprts indicating grup membership and careful examinatin f existing and planned grups is recmmended. A cuple rules f thumb shuld be cnsidered when creating subgrups. 1. Determine if yu can accmplish the same gal withut using subgrups. 2. Keep the subgruping as flat and as simple as pssible. The mre subgruping levels, the mre difficult it is t understand the lgic flw frm ne level t higher levels. Depending n the cmplexity f the subgrups, the lgic can increase as much as n 2, where n is the number f grup layers. The dependencies lgic will als becme cmplicated. Perhaps after setting up this gruping and rlling ut the status t maps and user views, yu get a cmplaint frm the inventry management department. Their cmplaint is that it is hard t see in the current gruping, if there is a prblem directly affecting their data prcessing dne in the datacenter. Because they are such a small prtin f the data center, they must investigate what caused DC-1 s status t change t see if any f their critical devices are in truble. This is time cnsuming and causes what they are calling false psitives.

8 8 Using Orin Grups and Dependencies This department uses tw nn-redundant applicatin servers, the clustered database, an IP path t the input web prtal ffsite and an IP path t a business partner cnnectin. They dn t really care t see that a redundant link r redundant equipment is dwn. They just want t knw if the inventry management system is wrking r nt. With this in mind, here is what we create. First, we create a DC-1 Inventry- Mgmt grup. Then, we add the same grups fr the entire redundant netwrk infrastructure as we did in the DC-1 grup, but we set the status f each t Best. This is because they are nly interested in knwing the datacenter netwrk wrks fr what they need. With the high level f redundancy, chances are, the best rllup status fr these items will always be Up. We dn t need t add the redundant servers, as they dn t use thse. Then, we add the DB cluster and individual applicatin servers as individual static members f DC-1 Inventry-Mgmt grup. Nw, we set the DC-1 Inventry-Mgmt grup rllup status. Because the servers are nn-redundant, we need t shw that there is a prblem with thse r with the database. Therefre, we set the DC-1 Inventry-Mgmt tp-level rllup t Wrst. Nw if any single, nn-redundant prtin fails r if there are any cmplete failures acrss a redundant prtin f the netwrk, the tp-level grup will indicate a failure in Inventry Management within the datacenter. But, what abut the partner cnnectin and web interface? If we culd add the business partner interface management and prtal testing as part f ur grup, this wuld give a much mre cmplete picture f the abilities f the netwrk t supprt the Inventry Management business task. The grup functin built int Orin cre allws yu t add bjects frm Orin mdules.

9 Using Orin Grups and Dependencies 9 What we d nw is create an ICMP ech IP SLA peratin in Orin IP SLA Manager frm a pint in the datacenter t the internal business partner cnnectin prt. Intra-data center IP traffic nrmally has rund trip times measured in micrsecnds, s it desn t really matter where in the database we place the peratin. After creating the peratin, we add it t the DC-1 Inventry-Mgmt grup. Next, using the Orin Applicatin Mnitr, we add a user experience test fr lgging int the inventry manager web interface. This test is then added as an bject int the DC-1 Inventry-Mgmt grup. We may als add statistics n the applicatin servers vlumes t the DC-1 Inventry-Mgmt grup. Here is the final gruping. DC-1 Inventry-Mgmt Grup. Status Rllup = Wrst member status App server #1 as member App server #2 as member All server vlumes (#1 and #2) as members All direct cnnectins t server as individual members IP SLA ICMP ech peratin as member APM web test as member Cre switch grup as member. Status rllup = Best member status Cre switch prts grup as member. Status rllup = Best member status Service switch grup as member. Status rllup = Best member status Service switch prts grup as member. Status rllup = Best member status Distributin switch prts grup as member. Status rllup = Best member status Distributin switch grup as member. Status rllup = Best member status Yu wuld prbably further grup the switch prts by functin (inter cre cnnectin, cre t service, service t distributin, et cetera), but I have nt added thse as they are nt necessary t shw the functins f grups and subgrups. S, we have created a datacenter netwrk management grup and an inventry management business prcess management grup. Each has its wn gal and functins t meet the needs f each party. There are bjects that are members n multiple grups, grups with different rllup status as well as static and dynamic members f the grups. Using grups is a pwerful feature fr rganizing bjects and adding lgic t the relatinships between bjects. It als enables anther pwerful feature f Orin dependencies. Dependencies Orin allws fr tw types f dependencies, implicit dependencies and explicit dependencies. Implicit dependencies are part f the Orin cde and are implemented autmatically. These dependencies handle cases in which bjects are always dependent n high level (parent) bjects. Vlumes and interfaces are implicitly child bjects f the nde they belng t. Fr Applicatin Perfrmance Mnitr, applicatins are implicitly children f a nde status as well. In IP SLA Manager, IP SLA peratins are implicit children t the status f the nde at bth ends f an peratin. Explicit dependencies are dependencies yu define. They perate by checking the status f a parent bject yu have defined. If the parent bject status is Unreachable r Dwn, the child is set t Unreachable. Unreachable is a new status that is nt prpagated by Orin alerting by default, allwing fr a suppressin f false psitive alerts. Whenever an bjects parent bject has failed, r is part f a larger failure, the status assignment f Unreachable t all child bjects prevents a cascade f child bject alerts. This is mst cmmnly used in the case where a prtin f the netwrk is separated frm the lcatin husing the Orin server by a WAN cnnectin.

10 10 Using Orin Grups and Dependencies Let s cnsider remte site A. This site is cnnected t the headquarters, where the Orin server is installed, by tw WAN cnnectins. In site A there are several switches, servers and netwrk users. Site A is cmpletely dependent n the tw WAN cnnectins back t headquarters fr all peratins. T create a dependency which reflects this we will first create a grup fr the tw WAN prts at the headquarters and call it Site A WAN. Then we will create a grup called Site A and add all managed bjects cmpletely cntained in Site A.The end f the WAN cnnectins will be made int a grup called Site A WAN. That grup will nly cntain the tw WAN interfaces at the headquarters that are cnnected t Site A.

11 Using Orin Grups and Dependencies 11 Bth grups will use Mixed status rllup. We g n t create a dependency fr the Site A grup as the child f the Site A WAN grup. And then, we create an alert fr Site A ensuring we are alerted when the site A grup status in nt equal t Up and indicate in the alert actin the status f the ffending managed bject. This will alert when site A has an issue with any bject f site A and tell us what is causing it. If the WAN cnnectins fail t site A, the interfaces n the headquarters side will g dwn and we will nly receive an alert that the WAN grup has failed. We can insert an alert actin nting that site A is nw unreachable. In an alternate slutin which yields mre granularity, we wuld grup like items in Site A and create dependencies which flw frm the WAN links dwn int Site ne layer at a time. Here is what yu wuld create t accmplish this. Grup Site A WAN, cntaining WAN links t site A Grup Site A Ruters, cntaining the ruters Grup Site A Switches, cntaining the Switches Grup Site A Servers. cntaining the Servers Then we wuld create the fllwing dependencies Parent Site A WAN Site A Ruters Site A Switches Child Site A Ruters Site A Switches Site A Servers Keep in mind that yu can assign multiple parents by membership in multiple grups which may cause difficulties in trubleshting dependency prblems. Because f the flexibility built int these features, yu may create very cmplex and interdependent grups and dependencies. Whenever yu are creating grups and dependencies, the simplest methd will be the best. Mst grupings designs can be achieved with nly a single layer f sub gruping as shwn n pages 6 and 7. Alerting and Reprting Bth the Orin Advanced Alert Manager and Reprt Writer have been updated t include gruping capabilities. Fr infrmatin n grups and alerts please see Understanding Orin Advanced Alerts. Fr infrmatin n grups and reprts please see Understanding Orin Reprt Writer.