Automatisch unzippen op remote server

[Verwijderd]

Ok, eerst een korte schets.
Ik heb hier één server waarop alle data-entry hier terecht komt.
Deze data moet naar onze 3 database servers.
Oorspronkelijk was dit helemaal geen probleem.
We kopieerden gewoon 's nachts automatisch alles van de entry-server naar elk van de 3 database servers (3 x 5GB).
Nu zijn onze database servers wegens gebrek aan bandbreedte voor onze end-users verhuisd.
Heel leuk voor onze end-users, knudde voor onszelf. Terwijl we dit voorheen gewoon kopieerden op een uurtje of 2 tijd, duurt het nu ongeveer 24 uur.
Tegen de tijd dat de data eindelijk in de database staat is ze dus al verouderd.

Aangezien men geen extra software wil aanschaffen heeft men mij gevraagd om te kijken hoe dit probleem opgelost kan worden.

Nu is er een heel simpele oplossing, gewoon de data zippen en doorsturen.
Het doorsturen van data duurt nu nog ongeveer 1 uur. Dit alles wordt geregeld door middel van een aantal batch-files.
MAAR:
Nu zou ik dus ook van het moment dat de data is doorgestuurd alles moeten unzippen.
Hoe kan ik er nu voor zorgen dat dit automatisch gebeurt, op deze 3 remote servers? Enkel het startsein zou dus eigenlijk gegeven moeten worden door de entry-server, het uitpakken zou dan door de 3 database servers moeten gebeuren.

Heeft er iemand een idee? Kan ik dmv een .bat file op 1 server, een .bat file op een andere server starten?


(Ik heb al geprobeerd een oplossing te zoeken op google en met de search, alsook op een ander forum.)

[Microkid]

Gewoon een batch file schrijven met pkzip.exe die de boel zipt. Daarna in de batch file een schijf koppelen (net use v: \\server\share) en de zip file daar naartoe kopieren. Dan met de taskscheduler een taak schedulen die de boel daar uitpakt. Stel dat je de zip actie om 23:00 uur start en het duurt maar 30 minuten, dan zou je de uitpak actie om 24:00 kunnen schedulen.

Zoiets:

(op server1)
cd \data
pkzip -add -rec data.zip
net use v: \\server2\share
copy data.zip v:\
net use v: /del
at \\server2 24:00 c:\uitpak.bat

[ Voor 59% gewijzigd door Microkid op 01-09-2004 16:19 ]

[Verwijderd]

zou het niet kunnen, nadat die gezipt is, en gecopyied is... op die andere servers een service schrijven.. via firedeamon, die elke x uur start om te kijken of het bestand er op staat of niet... of werkt via een extra bestand, als dat er op staat... dan dat starte??? is maar een id...

[Verwijderd]

Ok, dat heb ik dus gedaan. Hiermee krijg ik mij data op de remote server.
Maar het is het pkunzip commando waar ik problemen mee heb, als ik dat op deze manier uitvoer, dan stuurt hij de gezipte data weer terug omdat hij de "lokale" cpu van de server waar de batchfile wordt uitgevoerd gaat gebruiken.
Dus dat kost mij dan nog meer tijd dan de data niet-gecomprimeerd door te sturen.

Maar kan ik geen batchfile die dit dan gaat unzippen opstarten op een remote server die dan ook de cpu's van de remote server gaat gebruiken?
Dus echt zuiver op die éne server waar dit moet unzipped worden?

En op de tweede reactie:
Firedaemon? Nog nooit gehoord, effe opzoeken...

[ Voor 8% gewijzigd door Verwijderd op 01-09-2004 16:17 ]

[Microkid]

Verwijderd schreef op 01 september 2004 @ 16:16:
Ok, dat heb ik dus gedaan. Hiermee krijg ik mij data op de remote server.
Maar het is het pkunzip commando waar ik problemen mee heb, als ik dat op deze manier uitvoer, dan stuurt hij de gezipte data weer terug omdat hij de "lokale" cpu van de server waar de batchfile wordt uitgevoerd gaat gebruiken.
Dus dat kost mij dan nog meer tijd dan de data niet-gecomprimeerd door te sturen.

Maar kan ik geen batchfile die dit dan gaat unzippen opstarten op een remote server die dan ook de cpu's van de remote server gaat gebruiken?
Dus echt zuiver op die éne server waar dit moet unzipped worden?

En op de tweede reactie:
Firedaemon? Nog nooit gehoord, effe opzoeken...

Klopt, omdat je het pkunzip commando op je lokale server laat draaien. Als je het scheduled op die andere server moet het op die CPU gaan draaien.

[Verwijderd]

Microkid schreef op 01 september 2004 @ 16:09:
Stel dat je de zip actie om 23:00 uur start en het duurt maar 30 minuten, dan zou je de uitpak actie om 24:00 kunnen schedulen.

Dat zou inderdaad zeer eenvoudig zijn. Maar moeilijk haalbaar.
Het exporteren en aanpassen van de data duurt tussen de 2 en 4 uur. Het zippen en doorsturen, dat is ook moeilijk te zeggen hoe lang het juist duurt.
Ik kan het dus inderdaad wel gewoon schedulen op de 3 database servers, maar dan moet ik ook een veel te grote tijdsmarge nemen.

Ik heb het nu tijdelijk zo gedaan, maar deze situatie is dus verre van ideaal.
Ik zou het unzippen eigenlijk gewoon willen starten van het moment dat de volledige file doorgestuurd is.

[ Voor 8% gewijzigd door Verwijderd op 01-09-2004 16:23 ]

[ajhaverkamp]

Je kunt toch periodiek kijken of er een ZIP staat, zo ja uitpakken en ZIP weggooien/verplaatsen.

[Microkid]

Hoe groot zijn die bestanden? Anders zou je ook aan een DFS kunnen denken. Je maakt dan 2 nodes aan en de DFS zorgt er voor dat ze altijd in sync zijn. Wellicht het uitzoeken waard.

[Verwijderd]

Microkid schreef op 01 september 2004 @ 16:29:
Hoe groot zijn die bestanden?

Ongecomprimeerd is het ongeveer 5Gb.
Het is dus zo dat er hier op dit moment gewoon een enorm te kort is aan bandbreedte naar onze eigen server. Voor onze klanten is het veel beter, hun snelheid is opngeveer verdriedubbeld, die van ons daarentegen...
dus door middel van DFS die dingen gaan bijwerken, dat zou op dit moment gewoon veel te lang duren. (zelfs voor een zielige 15Gb in totaal)

[bogy]

ajhaverkamp schreef op 01 september 2004 @ 16:27:
Je kunt toch periodiek kijken of er een ZIP staat, zo ja uitpakken en ZIP weggooien/verplaatsen.

misschien moet je dit wel een beetje anders over de boeg gooien:

ipv te wachten op de "zip" file, laat je een scriptje checken op een .HIE (Hij Is Er) bestandje, dat je meekopieert telkens het zippen gedaan is (anders ga je vanuit een incomplete file unzippen, of moet je wachten tot hij volledig binnen is + evt overtime marge.

maw:

Batchfile illustraties

--batchfile op bronserver
Pkzip c:\db \\server2\blabla
Copy c:\zip.hie \\server2\blabla

-- batchfile op doelservre
if exist c:\blabla\zip.hie
then pkunzip c:\blabla\db.zip
else


vanaf dat er een .hie bestand aan is gekomen op de \\server2 mag hij starten met unzippen...
je moet dat .hie bestand bekijken als een soort van sleutelbestand om aan te geven dat alle voorgaande opdrachten volledig zijn uitgevoerd.

als het unzippen klaar is laat je dit .hie bestand natuurlijk verwijderen (of je script op server2 gaat herbeginnen met unzippen)

[spil]

Volgens mij heb jij pstools nodig! Een van de stukjes briljante freeware van SysInternals.com (zoek maar eens op sysinternals op microsoft.com)

http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

Onder andere heb je dan

quote: http://SysInternals.com

* PsExec - execute processes remotely

Je kunt dan dus in je batch-file een remote commando starten:

code:

psexec \\remotehost -u username -p password PakUitEnLaad.cmd Backup2.zip

Output komt op je lokale host terecht.

Alternatief zou je met scp (op windows met cygwin) de file over een compressed tunnel kunnen kopieren (scp -C user@host:file), dan hoef je niet eens in- en uit te pakken, dat verzorgd scp(ssh) voor je. Als je dan toch ssh hebt draaien op de remote, is het een koud kunstje om op de remote machine allerlei commands uit te voeren voor verwerken van de file.

PS. VirusScan rapporteert pskill en psexec als RemAdm-pskill RemAdm-ProcLaunch

[Verwijderd]

Bogy, dat lijkt mij inderdaad wel een mooie oplossing.
Maar ik heb eerlijk gezegd nog nooit een script geschreven dat ergens op moest wachten.
Hoe kan ik ervoor zorgen dat dat script telkens een tijdje wacht (5minuten of zo) voor hij opnieuw gaat kijken of dat bestand er is?

[Verwijderd]

spil schreef op 01 september 2004 @ 16:50:
Volgens mij heb jij pstools nodig! Een van de stukjes briljante freeware van SysInternals.com (zoek maar eens op sysinternals op microsoft.com)

Ok, dat ga ik dus ook nu dadelijk even bekijken.
Bedankt in ieder geval.

[Verwijderd]

Even een kleine update.
Met pstools kon ik het probleem perfect oplossen.
Gewoon het commando psexec om alles zuiver op de remote server uit te voeren.
Prachtige freeware, ideaal om zonder extra kostelijke software zulke problemen op te lossen.

[Verwijderd]

waarom schedule je niet op die drie remote servers dat zij moeten gaan kopieren en daarna uitpakken?

dus dat je hun het kopieer werk laat doen, dan kan de volgende regel het copy script "unzip" zijn

[Koffie]

Move NT > SA