Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Remote Storage von W2K Server nachbauen
1 view
Skip to first unread message
Kay Martinen
Jan 24, 2024, 4:50:03 AM1/24/24
to
Hallo
Mir fiel eben die Remote Storage Lösung unter Windows 2000 Server wieder
ein. Dabei wird Belegter Plattenspeicher mit Bandlaufwerken
virtualisiert. IMHO liegen die Dateien und Ordner immer noch auf der
Platte und könnten über eine Freigabe auch abgerufen werden. Aber wenn
die auf Tape ausgelagert waren dauert es nur länger bis die zurückgeholt
sind.
Ich hätte da eine ähnliche Idee für eine Anwendung aber die Details sind
unklar. Und zwar sei ein Internes Netzwerk gegeben in dem ein Normales
LAN und ein paar VLANs existieren. Und in diesen VLANs z.b. Altgeräte
wie Windows 2000 oder Management-Interfaces von Servern wie HP Ilo. Die
z.b. nicht nur Remote booten könnten sondern via ILO auch ein entferntes
Medium dem Host als Lokales Bootmedium ein klinken könnten.
Diese VLANs sollen nicht in's Internet und ein Zugriff durch den Router
dazwischen auf das normale LAN ist auch nicht gut. Daher wäre die Idee
in diesen VLANs bootmedien/images zu platzieren für den Fall das man neu
installieren müsse oder wolle. Also eher selten! Dazu braucht es tftp,
PXE oder andere Dienste (nfs,smb) in diesen VLANs um dort direkt an die
images zu kommen. Es ist aber ebenso ineffizient die images nur dort und
immer auf der (dann größeren) Platte liegen zu lassen.
Besser wäre es diese Images Zentral auf einem Fileserver im normalen LAN
liegen zu haben und den zugriff nur durch zu reichen.
Ein Router zwischen LAN und VLANs könnte so kleiner ausfallen, braucht
weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des Fileservers
in diesem Zwischenrouter mountet und dort den gleichen Pfad z.b. via
tftpd ins VLAN frei gibt, dies image als bootfile in dessen dhcpd
einträgt und ggf. die zusatzinfos (?) dazu anlegt.
Theoretisch sollte das funktionieren denke ich. Der Platzbedarf auf dem
zwischenrouter dürfte dann minimal sein. Wenn wirklich ein bootender
zugriff statt fände, was ist dann mit dem Datendurchsatz, evtl.
verzögerungen und was macht der bootende client wenn der datenstrom stockt?
Das ist jetzt immer noch keine Virtualisierung, nur eine Verlagerung mit
einem Stellvertreter.
Geht es auch anders? Mehr wie der Remote Storage, das die Dateien erst
dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
gebraucht werden? Und danach der Belegte Platz automatisch wieder frei
geräumt wird.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Mir fiel eben die Remote Storage Lösung unter Windows 2000 Server wieder
ein. Dabei wird Belegter Plattenspeicher mit Bandlaufwerken
virtualisiert. IMHO liegen die Dateien und Ordner immer noch auf der
Platte und könnten über eine Freigabe auch abgerufen werden. Aber wenn
die auf Tape ausgelagert waren dauert es nur länger bis die zurückgeholt
sind.
Ich hätte da eine ähnliche Idee für eine Anwendung aber die Details sind
unklar. Und zwar sei ein Internes Netzwerk gegeben in dem ein Normales
LAN und ein paar VLANs existieren. Und in diesen VLANs z.b. Altgeräte
wie Windows 2000 oder Management-Interfaces von Servern wie HP Ilo. Die
z.b. nicht nur Remote booten könnten sondern via ILO auch ein entferntes
Medium dem Host als Lokales Bootmedium ein klinken könnten.
Diese VLANs sollen nicht in's Internet und ein Zugriff durch den Router
dazwischen auf das normale LAN ist auch nicht gut. Daher wäre die Idee
in diesen VLANs bootmedien/images zu platzieren für den Fall das man neu
installieren müsse oder wolle. Also eher selten! Dazu braucht es tftp,
PXE oder andere Dienste (nfs,smb) in diesen VLANs um dort direkt an die
images zu kommen. Es ist aber ebenso ineffizient die images nur dort und
immer auf der (dann größeren) Platte liegen zu lassen.
Besser wäre es diese Images Zentral auf einem Fileserver im normalen LAN
liegen zu haben und den zugriff nur durch zu reichen.
Ein Router zwischen LAN und VLANs könnte so kleiner ausfallen, braucht
weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des Fileservers
in diesem Zwischenrouter mountet und dort den gleichen Pfad z.b. via
tftpd ins VLAN frei gibt, dies image als bootfile in dessen dhcpd
einträgt und ggf. die zusatzinfos (?) dazu anlegt.
Theoretisch sollte das funktionieren denke ich. Der Platzbedarf auf dem
zwischenrouter dürfte dann minimal sein. Wenn wirklich ein bootender
zugriff statt fände, was ist dann mit dem Datendurchsatz, evtl.
verzögerungen und was macht der bootende client wenn der datenstrom stockt?
Das ist jetzt immer noch keine Virtualisierung, nur eine Verlagerung mit
einem Stellvertreter.
Geht es auch anders? Mehr wie der Remote Storage, das die Dateien erst
dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
gebraucht werden? Und danach der Belegte Platz automatisch wieder frei
geräumt wird.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Marco Moock
Jan 24, 2024, 5:33:21 AM1/24/24
to
Am 24.01.2024 um 10:45:14 Uhr schrieb Kay Martinen:
> Theoretisch sollte das funktionieren denke ich.
Ja, aber wird ein Knoten im Hirn bei den vielen Bestandteilen.
> Theoretisch sollte das funktionieren denke ich.
> Der Platzbedarf auf dem zwischenrouter dürfte dann minimal sein.
> Wenn wirklich ein bootender zugriff statt fände, was ist dann mit dem Datendurchsatz,
> evtl. verzögerungen und was macht der bootende client wenn der
> datenstrom stockt?
Natürlich nicht bei 0,5s, aber vermutlich bei 10s.
Müsstest du testen.
Marcel Mueller
Jan 24, 2024, 6:39:25 PM1/24/24
to
Am 24.01.24 um 10:45 schrieb Kay Martinen:
> Ein Router zwischen LAN und VLANs könnte so kleiner ausfallen, braucht
> weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
Ein _Router_ hat keinen Plattenplatz.
> Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des Fileservers
> in diesem Zwischenrouter mountet und dort den gleichen Pfad z.b. via
> tftpd ins VLAN frei gibt, dies image als bootfile in dessen dhcpd
> einträgt und ggf. die zusatzinfos (?) dazu anlegt.
Es dürfte dem tftpd ziemlich egal sein, auf welchem Dateisystem die
Daten liegen.
> Theoretisch sollte das funktionieren denke ich. Der Platzbedarf auf dem
> zwischenrouter dürfte dann minimal sein. Wenn wirklich ein bootender
> zugriff statt fände, was ist dann mit dem Datendurchsatz, evtl.
> verzögerungen und was macht der bootende client wenn der datenstrom stockt?
Warten. Und wenn er keine Lust mehr hat: aufgeben.
> Geht es auch anders? Mehr wie der Remote Storage, das die Dateien erst
> dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
> gebraucht werden?
Was soll das in diesem Fall bringen? Auf die Anforderung zur Replikation
müsstest du auch warten. Und warum sollte man die Daten nicht gleich
durchreichen? Im Gegenteil, wenn man erst ausliefert, nachdem das Image
repliziert ist, geht es noch langsamer, weil die beiden Netzwerkstrecken
nicht mehr gleichzeitig arbeiten. Zudem riskiert man Timeouts beim
ersten Request.
> Und danach der Belegte Platz automatisch wieder frei
> geräumt wird.
Fragt sich nur wozu der Cache? Es kann am Ende keinesfalls schneller
gehen, als die Verbindung zur eigentlichen Datenquelle her gibt.
Jedenfalls, wenn man der Arbeitshypothese glaubt, dass es typischerweise
keine Cache-Hits sind.
Aber warum der ganze Aufwand? Ich würde der Datenquelle einfache eine
zweite IP-Adresse im VLAN geben und dort die gewünschten Daten
zusätzlich per tftp exponieren. Je nach Anforderung braucht es dafür
nicht einmal eine zweite Netzwerkkarte.
Marcel
> Besser wäre es diese Images Zentral auf einem Fileserver im normalen LAN
> liegen zu haben und den zugriff nur durch zu reichen.
Ack.
> liegen zu haben und den zugriff nur durch zu reichen.
> Ein Router zwischen LAN und VLANs könnte so kleiner ausfallen, braucht
> weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
> Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des Fileservers
> in diesem Zwischenrouter mountet und dort den gleichen Pfad z.b. via
> tftpd ins VLAN frei gibt, dies image als bootfile in dessen dhcpd
> einträgt und ggf. die zusatzinfos (?) dazu anlegt.
Daten liegen.
> Theoretisch sollte das funktionieren denke ich. Der Platzbedarf auf dem
> zwischenrouter dürfte dann minimal sein. Wenn wirklich ein bootender
> zugriff statt fände, was ist dann mit dem Datendurchsatz, evtl.
> verzögerungen und was macht der bootende client wenn der datenstrom stockt?
> Geht es auch anders? Mehr wie der Remote Storage, das die Dateien erst
> dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
> gebraucht werden?
müsstest du auch warten. Und warum sollte man die Daten nicht gleich
durchreichen? Im Gegenteil, wenn man erst ausliefert, nachdem das Image
repliziert ist, geht es noch langsamer, weil die beiden Netzwerkstrecken
nicht mehr gleichzeitig arbeiten. Zudem riskiert man Timeouts beim
ersten Request.
> Und danach der Belegte Platz automatisch wieder frei
> geräumt wird.
gehen, als die Verbindung zur eigentlichen Datenquelle her gibt.
Jedenfalls, wenn man der Arbeitshypothese glaubt, dass es typischerweise
keine Cache-Hits sind.
Aber warum der ganze Aufwand? Ich würde der Datenquelle einfache eine
zweite IP-Adresse im VLAN geben und dort die gewünschten Daten
zusätzlich per tftp exponieren. Je nach Anforderung braucht es dafür
nicht einmal eine zweite Netzwerkkarte.
Marcel
Alexander Goetzenstein
Jan 25, 2024, 1:32:45 AM1/25/24
to
Hallo,
Am 24.01.24 um 11:33 schrieb Marco Moock:
kommt auf die Bandtechnik an, das kann schon mal eine halbe Stunde
werden -pro Datei. Dateien des Betriebssystems sollten aber eher nicht
in die Auslagerung geraten, sondern nur längere Zeit nicht angefasste Daten.
--
Gruß
Alex
Am 24.01.24 um 11:33 schrieb Marco Moock:
werden -pro Datei. Dateien des Betriebssystems sollten aber eher nicht
in die Auslagerung geraten, sondern nur längere Zeit nicht angefasste Daten.
--
Gruß
Alex
Marco Moock
Jan 25, 2024, 2:21:44 AM1/25/24
to
Am 25.01.2024 um 07:32:41 Uhr schrieb Alexander Goetzenstein:
> kommt auf die Bandtechnik an, das kann schon mal eine halbe Stunde
> werden -pro Datei. Dateien des Betriebssystems sollten aber eher nicht
> in die Auslagerung geraten, sondern nur längere Zeit nicht angefasste
> Daten.
Dann ist das für alle Prozesse, die halbwegs normale Netzwerk-Timeouts
> kommt auf die Bandtechnik an, das kann schon mal eine halbe Stunde
> werden -pro Datei. Dateien des Betriebssystems sollten aber eher nicht
> in die Auslagerung geraten, sondern nur längere Zeit nicht angefasste
> Daten.
haben, ungeeignet.
PXE-Boot wird darunterfallen.
Dateien von OS oder Programmen, die ausgeführt werden, ebenfalls.
Marco Moock
Jan 25, 2024, 2:26:44 AM1/25/24
to
Am 25.01.2024 um 00:39:23 Uhr schrieb Marcel Mueller:
> Ein _Router_ hat keinen Plattenplatz.
Cisco-Router haben ne USB-Schnittstelle. USB-Platten könnten da
> Ein _Router_ hat keinen Plattenplatz.
funktionieren. Sticks tun es.
Serverdienste wie scp, ftp bieten die auch.
Auch die FB bietet sowas.
Kay Martinen
Feb 4, 2024, 4:20:02 PM2/4/24
to
Am 25.01.24 um 00:39 schrieb Marcel Mueller:
>> Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des
>> Fileservers in diesem Zwischenrouter mountet und dort den gleichen
>> Pfad z.b. via tftpd ins VLAN frei gibt, dies image als bootfile in
dann doch sinnvoller.
> Aber warum der ganze Aufwand? Ich würde der Datenquelle einfache eine
> zweite IP-Adresse im VLAN geben und dort die gewünschten Daten
> zusätzlich per tftp exponieren. Je nach Anforderung braucht es dafür
> nicht einmal eine zweite Netzwerkkarte.
Damit wollte ich ja eben vermeiden das ein Client im VLAN direkt via IP
auf den Fileserver (der ja im Normalen LAN bleiben soll) zugreifen könnte.
Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
welchem nicht.
Beispiel EISFAIR. Bei einigen kann man nur IP-Netz, bei anderen nur die
NIC wählen aber das ist nicht durchgängig.
Und ob das z.b. bei OMV besser ist...? Auf einem Einfachen Debian kann
man sicher alles zu fuß einrichten aber wenn man es bequemer haben
wollte sind das eben oft die Kompromisse. Faule, oder Faulheit. :-)
Kay
> Am 24.01.24 um 10:45 schrieb Kay Martinen:
>> Besser wäre es diese Images Zentral auf einem Fileserver im normalen
>> LAN liegen zu haben und den zugriff nur durch zu reichen.
>> Besser wäre es diese Images Zentral auf einem Fileserver im normalen
>> LAN liegen zu haben und den zugriff nur durch zu reichen.
>> Ein Router zwischen LAN und VLANs könnte so kleiner ausfallen, braucht
>> weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
>
> Ein _Router_ hat keinen Plattenplatz.
Nachtrag: Ich meinte einen Software-router, keine Feststehende Hardware.
>> weniger Plattenplatz und müsste nur als Stellvertreter/Proxy fungieren.
>
> Ein _Router_ hat keinen Plattenplatz.
>> Aber welchen Effekt hätte es wenn man z.b. ein nfs-share des
>> Fileservers in diesem Zwischenrouter mountet und dort den gleichen
>> Pfad z.b. via tftpd ins VLAN frei gibt, dies image als bootfile in
>> Geht es auch anders? Mehr wie der Remote Storage, das die Dateien erst
>> dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
>> gebraucht werden?
>> dann angefordert und z.b. Zwischengespeichert werden wenn sie wirklich
>> gebraucht werden?
> durchreichen? Im Gegenteil, wenn man erst ausliefert, nachdem das Image
> repliziert ist, geht es noch langsamer, weil die beiden Netzwerkstrecken
> nicht mehr gleichzeitig arbeiten. Zudem riskiert man Timeouts beim
> ersten Request.
Hast recht. Daran hatte ich noch nicht gedacht. Da wäre die O.g. Methode
> repliziert ist, geht es noch langsamer, weil die beiden Netzwerkstrecken
> nicht mehr gleichzeitig arbeiten. Zudem riskiert man Timeouts beim
> ersten Request.
dann doch sinnvoller.
> Aber warum der ganze Aufwand? Ich würde der Datenquelle einfache eine
> zweite IP-Adresse im VLAN geben und dort die gewünschten Daten
> zusätzlich per tftp exponieren. Je nach Anforderung braucht es dafür
> nicht einmal eine zweite Netzwerkkarte.
auf den Fileserver (der ja im Normalen LAN bleiben soll) zugreifen könnte.
Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
welchem nicht.
Beispiel EISFAIR. Bei einigen kann man nur IP-Netz, bei anderen nur die
NIC wählen aber das ist nicht durchgängig.
Und ob das z.b. bei OMV besser ist...? Auf einem Einfachen Debian kann
man sicher alles zu fuß einrichten aber wenn man es bequemer haben
wollte sind das eben oft die Kompromisse. Faule, oder Faulheit. :-)
Kay
Marco Moock
Feb 4, 2024, 4:30:18 PM2/4/24
to
Am 04.02.2024 22:16 Uhr schrieb Kay Martinen:
> Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
> festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
> welchem nicht.
Dann regelt man das halt über die Firewall.
> Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
> festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
> welchem nicht.
--
Gruß
Marco
Spam und Werbung bitte an ichschic...@cartoonies.org
Kay Martinen
Feb 5, 2024, 9:30:03 AM2/5/24
to
Am 04.02.24 um 22:30 schrieb Marco Moock:
einfach mal mit Brettern von außen dicht nageln. Toll. :-/
Besser wäre es ja schon die erst gar nicht eingebaut zu haben.
Hmm, Erinnert mich irgendwie an einen Wolkenkratzer der auf einer
Bretterbude steht... WeißAuchNich. :-)
> Am 04.02.2024 22:16 Uhr schrieb Kay Martinen:
>
>> Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
>> festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
>> welchem nicht.
>
> Dann regelt man das halt über die Firewall.
>
Aha. Also so, als würde man am Haus nicht benutzte Fenster und Türen
>
>> Nicht bei jeder Server-lösung oder Software kann man immer pro Dienst
>> festlegen auf welcher NIC, IP/Port, (V)LAN er lauschen soll, und auf
>> welchem nicht.
>
> Dann regelt man das halt über die Firewall.
>
einfach mal mit Brettern von außen dicht nageln. Toll. :-/
Besser wäre es ja schon die erst gar nicht eingebaut zu haben.
Hmm, Erinnert mich irgendwie an einen Wolkenkratzer der auf einer
Bretterbude steht... WeißAuchNich. :-)
Tim Ritberg
Feb 5, 2024, 2:01:44 PM2/5/24
to
Am 05.02.24 um 15:29 schrieb Kay Martinen:
> Hmm, Erinnert mich irgendwie an einen Wolkenkratzer der auf einer
> Bretterbude steht... WeißAuchNich. :-)
So ein Bild gab es mal in der c't für Windows.
Tim
> Hmm, Erinnert mich irgendwie an einen Wolkenkratzer der auf einer
> Bretterbude steht... WeißAuchNich. :-)
Tim
Kay Martinen
Feb 5, 2024, 3:50:03 PM2/5/24
to
Am 05.02.24 um 20:01 schrieb Tim Ritberg:
Ich weiß. ;-) Genau das meinte ich!
Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
Tim Ritberg
Feb 5, 2024, 4:55:47 PM2/5/24
to
Am 05.02.24 um 21:44 schrieb Kay Martinen:
> Ich weiß. ;-) Genau das meinte ich!
>
> Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
> Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
> sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
Ich hab die c't auch irgendwo.
Das Thema war aber wohl DPMI
Tim
> Ich weiß. ;-) Genau das meinte ich!
>
> Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
> Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
> sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
Das Thema war aber wohl DPMI
Tim
Kay Martinen
Feb 12, 2024, 7:20:03 PM2/12/24
to
Am 05.02.24 um 22:55 schrieb Tim Ritberg:
> Das Thema war aber wohl DPMI
Glaub ich weniger. Das Editorial zu dem Bild befaßte sich m.E. mit der
Windows historie. DOS Aufsatz und die Evolution drum herum. Das es da
nur um DPMI ginge nehme ich nicht an.
Darum ja auch das Bild, Windschiefe Bretterbude und obendrauf; mit
Verstrebungen/Stützen ein Schillernder Glaspalast.
Naja, Scherben bringen Glück oder? ;)
> Am 05.02.24 um 21:44 schrieb Kay Martinen:
>
>> Ich weiß. ;-) Genau das meinte ich!
>>
>> Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
>> Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
>> sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
>
> Ich hab die c't auch irgendwo.
Ich sicher auch - irgendwo!
>
>> Ich weiß. ;-) Genau das meinte ich!
>>
>> Vor einiger Zeit hatte ich es mal gesucht, gefunden und gespeichert.
>> Aber jetzt finde ich keine URL dazu. Obwohl das doch recht bekannt sein
>> sollte. Ob da der Zensor mal NICHT pinkeln war? ;-)
>
> Ich hab die c't auch irgendwo.
> Das Thema war aber wohl DPMI
Windows historie. DOS Aufsatz und die Evolution drum herum. Das es da
nur um DPMI ginge nehme ich nicht an.
Darum ja auch das Bild, Windschiefe Bretterbude und obendrauf; mit
Verstrebungen/Stützen ein Schillernder Glaspalast.
Naja, Scherben bringen Glück oder? ;)
0 new messages