(Novell) synthetic servertime :(

[Verwijderd]

Het is dus gebeurd zoals je als titel kunt zien.
De server heeft een synthetic servertime lopen die dat elke 2 minuten op de console meldt.
De ellende is begonnen nadat de backupsoftware van ARCserve muurvast zat en de enigste mogelijkheid nog was om de server te herstarten.
Dit ging gelukkig zonder dat Novell ergens op bleef hangen en de server ging zonder problemen down.
Nadat de server weer gestart was en dit zonder problemen deed viel het me op dat de server een uur achter liep.
Dit vond ik vreemd en heb de parameters op in de consolemonitor gecontroleerd.
De timezone staat goed evenals de zomertijd instellingen van een uur.
Ik heb geprobeerd de server vooruit te zetten (en dat had ik waarschijnlijk niet moeten doen.) en hij sprong 2 (twee uur vooruit!
Ja raadt het al met reset flags ging de server weer twee uur achterlopen maar genereerde de synthetic time!
Ik weet dat als de synthetic time komt je het beste gewoon moet wachten totdat Novell weer langzaam goed gaat lopen maar na een uur of drie scheelde het nog geen seconde!
Wat ik ook vreemd vond is dat de server meldt dat de daylight op 7 april moet gaan beginnen terwijl in de autoexec.ncf staat dat de daylight op de eerste zondag van April begint.
Betekend dit dat als je na de zomertijd opnieuw de server start, Novell de zomertijd de volgende zondag o.i.d. laat beginnen?
Dat weet ik dus niet.
Er zou een mogelijkheid zijn om de servertijd echt te resetten (iets in DSTRACE meen ik) maar zeker weten doe ik dat niet en ik ben ook bang dat er problemen ontstaan die groter zijn als de synthetic timemelding met bijbehorend piepje.
Ter info : Novell Netware 5.0 met SP6.
Als iemand me op weg kan helpen verneem ik dat graag.

[Zwelgje]

code:

load dsrepair -a    (advanced options..(destructive!))

dat zou hem moeten doen, je hebt dan een optie erbij in het dsrepair menu (iets in de trant van '...and declare new epoc'

....sorry van het niet complete antwoord, maar ik heb hier even geen netware server in de buurt

check ook

http://www.novell.com/documentation/lg/nw6p/index.html?utlrfenu/data/hneidcah.html

[Verwijderd]

Als je Novell niet goed genoeg kent GEEN declare a new epoch doen !! Dan worden je replica's verwijderd en opnieuw aangemaakt. Kan bijzonder destructief zijn als het je master betreft.

Beginnen met tijd goed zetten op de server met de master replica. Controleren of er 1 server single reference of reference timeserver is. Alle andere servers als secondary.

Dan:
set timesync restart flag = on (op alle servers).

Vervolgens:
set dstrace=on
set dstrace=+s
set dstrace=*f
set dstrace=*h

Vervolgens afwachten, de tijd gaat vanzelf goed lopen.
Nogmaals, verkloot je de tijd synchronisatie in je replica's dan is je NDS ook gelijk kaduuk.

[Zwelgje]

Op zondag 07 april 2002 00:54 schreef Noveller het volgende:
Als je Novell niet goed genoeg kent GEEN declare a new epoch doen !! Dan worden je replica's verwijderd en opnieuw aangemaakt. Kan bijzonder destructief zijn als het je master betreft.

Beginnen met tijd goed zetten op de server met de master replica. Controleren of er 1 server single reference of reference timeserver is. Alle andere servers als secondary.

Dan:
set timesync restart flag = on (op alle servers).

Vervolgens:
set dstrace=on
set dstrace=+s
set dstrace=*f
set dstrace=*h

Vervolgens afwachten, de tijd gaat vanzelf goed lopen.
Nogmaals, verkloot je de tijd synchronisatie in je replica's dan is je NDS ook gelijk kaduuk.

mm ik heb dit altijd gebruikt op die manier (stond ook in een TID van novell toendertijd, had er nooit geen problemen mee, en zekers niet dat mijn hele nds om zeep werd geholpen,

toegeven als je niet weet waar je mee bezig bent kan het erg 'destructief' zijn...

[Onno]

Op zaterdag 06 april 2002 20:54 schreef pinolief het volgende:
De ellende is begonnen nadat de backupsoftware van ARCserve muurvast zat en de enigste mogelijkheid nog was om de server te herstarten.

Ik denk niet dat het daar ook maar iets mee te maken heeft.

Nadat de server weer gestart was en dit zonder problemen deed viel het me op dat de server een uur achter liep.

Dat is vrij logisch, je geeft zelf het antwoord al:

Wat ik ook vreemd vond is dat de server meldt dat de daylight op 7 april moet gaan beginnen terwijl in de autoexec.ncf staat dat de daylight op de eerste zondag van April begint.

Dat is om te beginnen niet vreemd, want 7 april is gewoon de eerste zondag van april. Maar het is wel onjuist, want de zomertijd begon op de laatste zondag van maart. Vorige week dus. En daarom liep je server dus een uur achter..

Op zondag 07 april 2002 00:54 schreef Noveller het volgende:
Als je Novell niet goed genoeg kent GEEN declare a new epoch doen !! Dan worden je replica's verwijderd en opnieuw aangemaakt. Kan bijzonder destructief zijn als het je master betreft.

Dat is niet zo. Alle timestamps worden gereset, maar er wordt niets verwijderd. (en het is *juist* iets dat op je master gebeurt)

[Verwijderd]

@Onno:

Het heeft ook niets met de backup te maken.
Ik bedoelde er mee te zeggen dat vanaf het punt dat ik erachter kwam dat de backup vast stond ik van de regen in de drup kwam.
Ik moest door dit probleem noodgedwongen herstarten (de tijd liep toen naar mijn weten gewoon goed) en daarna ondstond (dacht ik ) het tijdprobleem vandaar mijn eerste zin.
Wat betreft de zomertijd heb je gewoon gelijk, deze is begonnen op 31maart en volgens de instellingen van Novell zou die op de eerste week van April beginnen.

Nou, het is nu maandag en de problemen zijn zo te zien opgelost omdat er eigenlijk na het nog een keer hestarten van de server (vrijdagavond al, maar toen was ik blij dat ik naar huis kon)er geen probleem met de tijdsync van Novell is.
"synthetic time issued" komt niet voor (ook niet in de consolelog van afgelopen weekend) en de zomertijd is idd op 7 april s'nachts om 02.00uur op de server ingegaan.
Novell geeft de juiste tijd aan, "synthetic time" is het niet en de backup van afgelopen weekend is gelukt.
Allen bedankt voor de suggesties en tips die gelukkig hier niet nodig zijn geweest maar wel zijn opgeslagen!

[Verwijderd]

Ik had het niet helemaal goed omschreven:

Declaring a new epoch can be a touchy thing. (Check out all the folks scurrying about buying generators and canned ham for Y2K.) When you declare a new epoch, you'll lose changes made in a previous epoch. For example, changes to a read/write replica will be lost if they have not yet been synchronized to all other copies, including the master. If a modification has not yet been synchronized to the master replica before a new epoch is declared, the change is lost. But that's not the end of it. All the servers in the replica ring that are running Bindery Services will lose their bindery context. (This is a result of the fact that declaring a new epoch essentially tells the server to delete the replica (and no replica means no bindery context is possible) and then download a new copy from the master.


Alle read/write replica's worden gewist en krijgen nieuwe replica's van de master. Als je master niet honderd procent in orde is dan blijven die nieuwe replica's in een stuck state hangen.

Het is dus niet zo alleen de timestamps verwijderd worden, alle read/writes worden gewist en opnieuw aangemaakt.
Trouwens een ellende als er WAN links tussen liggen.

[Verwijderd]

Op maandag 08 april 2002 21:42 schreef Noveller het volgende:
Ik had het niet helemaal goed omschreven:

Declaring a new epoch can be a touchy thing. (Check out all the folks scurrying about buying generators and canned ham for Y2K.) When you declare a new epoch, you'll lose changes made in a previous epoch. For example, changes to a read/write replica will be lost if they have not yet been synchronized to all other copies, including the master. If a modification has not yet been synchronized to the master replica before a new epoch is declared, the change is lost. But that's not the end of it. All the servers in the replica ring that are running Bindery Services will lose their bindery context. (This is a result of the fact that declaring a new epoch essentially tells the server to delete the replica (and no replica means no bindery context is possible) and then download a new copy from the master.


Alle read/write replica's worden gewist en krijgen nieuwe replica's van de master. Als je master niet honderd procent in orde is dan blijven die nieuwe replica's in een stuck state hangen.

Het is dus niet zo alleen de timestamps verwijderd worden, alle read/writes worden gewist en opnieuw aangemaakt.
Trouwens een ellende als er WAN links tussen liggen.

Dit klinkt als een behoorlijk risico om een dergelijke actie uit te voeren.
Mij lijkt het dus deze extreme actie alleen te doen als er echt geen andere uitweg meer is.
Nu is het wel zo dat ik geen last van replicaservers heb om de eenvoudige reden dat hier maar 1 Netware server staat en dus gelijk de masterreplica is.
De Engelse tekst die je citeerd heb ik bij Novell ook gelezen en toen al dacht ik dat deze actie alleen maar gedaan moest worden als het echt niet anders kan.
Gelukkig draait hier 1 Novellserver en waren er nog maar een paar users ingelogd dus het opnieuw downen van de server was geen probleem en zoals hiervoor la vermeld is er nu niets meer aan de hand met de tijdsynchronisatie.
In ieder geval bedankt voor je reacties, Noveller.

[Verwijderd]

He, ff vraagje... beetje off-topic... Gaat dit over het ID college in gouda toevallig?

[supernova]

Op dinsdag 09 april 2002 09:57 schreef pinolief het volgende:

[..]

Dit klinkt als een behoorlijk risico om een dergelijke actie uit te voeren.
Mij lijkt het dus deze extreme actie alleen te doen als er echt geen andere uitweg meer is.
Nu is het wel zo dat ik geen last van replicaservers heb om de eenvoudige reden dat hier maar 1 Netware server staat en dus gelijk de masterreplica is.
De Engelse tekst die je citeerd heb ik bij Novell ook gelezen en toen al dacht ik dat deze actie alleen maar gedaan moest worden als het echt niet anders kan.
Gelukkig draait hier 1 Novellserver en waren er nog maar een paar users ingelogd dus het opnieuw downen van de server was geen probleem en zoals hiervoor la vermeld is er nu niets meer aan de hand met de tijdsynchronisatie.
In ieder geval bedankt voor je reacties, Noveller.

Ok een antwoord het slaat nergen op......

Het einige wat hi doet is de timestamp binnen de NDS aanpassen...
Even simple gezegd....

Maar hij gooid echt niet de replica's weg.. dat is klink klare onzin...

Ik heb het al vaker gedaan als en nog nooit problemen gehad. en als je zelf een tijdje wacht dan gaat die syntehic time vanzelf weg.... ( het kan een paar uur duren maar daarna is het vanzelf opgelost..

[Verwijderd]

Op dinsdag 09 april 2002 10:46 schreef Viper3.5 het volgende:
He, ff vraagje... beetje off-topic... Gaat dit over het ID college in gouda toevallig?

Nee..waarom vraag je dat?