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?" :-)

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.

> Der Platzbedarf auf dem zwischenrouter dürfte dann minimal sein.

Weiß ich nicht, Stichwort Cache.

> 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?

Timeout und Abbruch, wenn das zu extrem ist.
Natürlich nicht bei 0,5s, aber vermutlich bei 10s.
Müsstest du testen.

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.

Ack.

> 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

Hallo,

Am 24.01.24 um 11:33 schrieb Marco Moock:
> 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.
>
>> Der Platzbedarf auf dem zwischenrouter dürfte dann minimal sein.
>
> Weiß ich nicht, Stichwort Cache.
>
>> 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?
>
> Timeout und Abbruch, wenn das zu extrem ist.
> Natürlich nicht bei 0,5s, aber vermutlich bei 10s.
> Müsstest du testen.

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 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
haben, ungeeignet.
PXE-Boot wird darunterfallen.
Dateien von OS oder Programmen, die ausgeführt werden, ebenfalls.

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
funktionieren. Sticks tun es.
Serverdienste wie scp, ftp bieten die auch.
Auch die FB bietet sowas.

Am 25.01.24 um 00:39 schrieb Marcel Mueller:
> 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.
>> 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.

>> 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?

> 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
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 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.

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Am 04.02.24 um 22:30 schrieb Marco Moock:
> 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
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. :-)

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

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

Am 05.02.24 um 20:01 schrieb Tim Ritberg:
> 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.

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? ;-)

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

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

Am 05.02.24 um 22:55 schrieb Tim Ritberg:
> 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!

> 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? ;)

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)