Server Status

[dorkyman]

Moin Gemeinde,
mal wieder ne "Dussel-Frage" von Hobby-Admin Dorky:

Unser Domino lief jahrelang mit folgender  availability: Verfügbarkeitsindex:  100 (Status: AVAILABLE). Nun isset nur noch: Verfügbarkeitsindex:  70 (Status: AVAILABLE).

Was soll mir das sagen? Serverlast zu hoch?

Wär´ schön wenn ihr mir das beantworten könntet.

Grüße

Dorky

[adminnaddel]

Hallo,

so ähnlich habe ich nun auch das Problem am Haken! Im Clusterverbund scheint der Verfügbarkeitsindex plötzlich auf 70% abzusinken??!!

Was könnte man machen um heruas zu finden, welche Applikation Streß macht? Es handelt sich hierbei nur um Anwendungen innerhalb des Clusters, nicht um MailRouting!

Grüße

[Driri]

Habt ihr von R5 auf 6.5 gewechselt ? Ab Domino 6 oder 6.5 wurde die Berechnung des Availability Index geändert, da können jetzt komplett andere Werte bei rauskommen.

Da gabs hier im Forum auch schon mal Threads zu.

[adminnaddel]

Sorry, nein!
Nicht gewechselt, seit 3 Jahren läuft der Cluster rund, jetzt bockt er!

Grüße

[Driri]

Hi,

ok, ist evtl. der Cluster-Replicator ziemlich dicht ? IMO wirkt sich das auch deutlich auf den AI aus.

Sonst lies dir mal diesen Tipp durch.

Dort wird beschrieben, wie man in der Statrep nen bißchen basteln kann, um sich einen Überblick verschaffen zu können.

[adminnaddel]

Danke, aber warum bist du dir sicher, das ich mich zum anschauen registrieren muss?

MEMBER LOG-IN
 Registered SearchDomino.com and TechTarget members please Log-in below.
 
Member ID:      (Note: This is your e-mail address.)
 
Password:   

 

Grüße

[Driri]

Oh, sorry, ich bin da registriert, von daher ist mir das nicht aufgefallen.

Hier mal der Artikel :

"There is nothing there!" he whined. Well, actually, there was something there, just not anything that he had worked on in the last two hours. And from the pained look on his face, I half expected this big and burly man to softly murmur, "My precious ... my precious...."

But to my Domino Upgrade project manager, it sure felt like everything was missing. The cluster had protected him by letting him fail over to his backup server when his mail server took a nosedive, but where were all the messages he received from 10 a.m. to noon, and what happened to the meetings he had planned?

They were gone! Victims of his mail server's inability to keep up with cluster replication. He would see these precious messages and appointments only after his mail server was raised from the dead -- and who knew how long that was going to be?

It's not that his mail server was a feeble box. It was a new system on a platform that could kick butt, carefully selected to handle the consolidated load of four old mail servers. The only problem was that no one had seriously monitored the box while users were migrated, and the cluster replicator had been overtaken by force. It was a full two hours behind.

Fortunately, this is a situation that's easy to avoid if you don't mind being a little proactive. If the cluster replication is falling behind, just add cluster_replicators= (number of replicators to use) to the server's Notes.ini and restart the server.

Lotus legends tell us that the number of cluster replicators should be some tangible factor like the number of processors used by the Domino server plus one, but I've found it more effective to use double the number of processors. You don't want to use too many though, as they do take resources that might be better used elsewhere.

You can tell if a server needs more cluster replicators by watching a pair of stats that are automatically generated and kept in StatRep.nsf. These are:

SecondsOnQueue: This tells you what the total time, in seconds, that the last database replicated spent waiting on the cluster's replication work queue.

WorkQueueDepthCurrent: This tells you the number of databases awaiting replication by the Cluster Replicator.

There are actually three versions of each of these stats:

Replica.Cluster.SecondsOnQueue
Replica.Cluster.SecondsOnQueue.Avg
Replica.Cluster.SecondsOnQueue.Max
Replica.Cluster.WorkQueueDepth
Replica.Cluster.WorkQueueDepth.Avg
Replica.Cluster.WorkQueueDepth.Max

Watch the max as an indicator of how bad things got, even for moment. The averages can vary a bit, but they are important trending indicators. The current snapshot should always be in the single digits. Anything other than that and the townspeople will fire up their torches, grab their pitchforks and storm your office when their server keels over, because the failover copy of their precious mail file or powerful all-knowing application will be missing their favorite part -- the part they added recently.

The problem is that getting to these stats is a pain in the neck. You need to bust open the console, and type: Show stat replica.cluster.* for each server in the joint. Or you need to go to Statrep and do a Document Properties and scroll through the field list.

And who has time for that nonsense? It's downright humiliating to be forced to actually work for a living! Administrators have better things to do, like dealing with users who accidentally delete their mail files.

Because this bit of cluster checking requires effort, it rarely gets done with enough regularity to spot cluster replication problems. It rarely gets fixed before it gets out of hand.

So, as I always say, if you can't win, change the rules.

Spark up Designer and have a whack at Statrep. Make a copy of the "Statistics Reports Clusters" and call it something terribly creative, like "Statistics Reports Clusters w/queue info." Then add three columns as follows:

Replica.Cluster.SecondsOnQueue/60
Replica.Cluster.SecondsOnQueue.Avg/60
Replica.Cluster.SecondsOnQueue.Max/60

Showing these stats as minutes rather than seconds makes the output easier to understand at a glance.

Then add three more:

Replica.Cluster.WorkQueueDepth
Replica.Cluster.WorkQueueDepth.Avg
Replica.Cluster.WorkQueueDepth.Max

Throw in an additional column using the field Server.Availability.Index if you want to see how hard your servers are working. The closer this gets to zero, the more sweat your box is generating.

If you are using 6.x you'll probably want to add an outline entry to the MainOutline that accommodates your cool new view.

Your easy bit of work will produce a beautiful and wonderfully informative view that looks like this:

Figure 1

You can impress your administrator friends and tell at a glance if you need more cluster replicators to keep everything in sync.

OK, OK ... you will still have to LOOK at statrep occasionally. I didn't say it would be all peaches and cream. Your server won't adjust its own cluster_replicator number.

Or will it? Perhaps I could write some sort of agent ... one linked to an event that checks the stat and then adjusts the parameter automatically for me -- according to my demands as its master!

On second thought, I think I'd rather let my human side deal with a decision to add cluster replicators. You must take into consideration all sorts of things that might not be readily apparent, such as a temporary load on the box, or the initialization of new replicas.

After all, server resources are really limited. They're quite finite. And well, they are downright precious to me.

[adminnaddel]

Vielen Dank,

werde schauen ob das was ist!

Grüße