home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
Language specific support
Deutsches MediaPortal Forum
Hard- und Software rund um den HTPC
Hardware
Mainboards/CPU/RAM
Neuer TV-Server mit speziellen Anforderungen
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="knuddelbaer1989" data-source="post: 1174018" data-attributes="member: 108341"><p>Meines Wissens kann Storage Spaces nur "Mirror", "Parity" und "Simple" und keine doppelte Parity wie bei RAID 6. (Es kann aber auch sein das ich hier noch auf dem Stand von Server 2008 R2 bin. Storage Spaces werden ja konsequent weiterentwickelt.)</p><p></p><p><a href="https://technet.microsoft.com/de-de/library/hh831739.aspx?f=255&MSPPError=-2147217396" target="_blank">https://technet.microsoft.com/de-de/library/hh831739.aspx?f=255&MSPPError=-2147217396</a></p><p></p><p>Das einfach weiterwachsen ist leider auch nur in der Theorie so... Was ich bisher gelesen habe, funktioniert das nur bedingt so. Einfach kleinere gegen größere Austauschen gehört auch nicht so ganz zum Konzept. Neue hin zustecken schon eher. Hier hängt das allerdings stark von den Columns ab, wie sie auf den Festplatten verteilt sind. Wenn du den Pool über Powershell anlegst hast du hier Einfluss drauf, ansonsten nicht. Umso höher die Columns umso schneller das Raid aber umso schwerer zu erweitern.</p><p></p><p>Beim Spiegeln verhält es sich so, dass immer im gleichen Maße aufgestockt werden muss. Heißt man verwendet 6 Festplatten im Spiegel und muss dann, wenn man es erweitern will, erneut 6 Festplatten dazu stecken.</p><p></p><p><a href="http://www.miru.ch/why-column-size-does-matter-with-storage-spaces/" target="_blank">http://www.miru.ch/why-column-size-does-matter-with-storage-spaces/</a></p><p></p><p>Ich gehe davon aus, dass es sich bei Parity ähnlich verhält, man findet hierzu allerdings nicht allzu viele Infos. Nur bei "Simple" ist das einfache erweitern möglich, da es ich hier ja auch nur im eine Art JBOD handelt und der neue Speicher einfach hinten angehängt wird.</p><p></p><p>Ich persönlich bin mir, umso mehr ich mich damit beschäftige, immer unsicherer ob es Storage Spaces werden oder ob ich es mache wie bisher (Festplatten in Ordner mounten, damit ich bei MpTVSeries oder Moving Pictures nur einen Laufwerksbuchstaben angeben muss).</p><p></p><p>Der Vorteil der Fehlersicherheit teilt sich den Nachteil mit der Komplexität und dem erschwerten Desaster Recovery. Bei meinem Momentanen Aufbau habe ich den Vorteil, dass wenn mein HTPC (dort sind zur Zeit alle Platten drin) den Geist aufgibt, ich einfach die HDDs in einen anderen Rechner hängen kann und dort alles auslesen kann. Ob das mit Storage Spaces so funktioniert bezweifle ich einfach mal und da ich auch kein Backup aller Daten machen werde (Bilder/Privates/Persönliches sind mehrfach gebackupt aber Aufnahmen und dergleichen sind mir nicht wichtig genug um einen 2. Server zu bertreiben der die selbe Kapazität vorweist). </p><p></p><p>Dann zu den Fragen</p><p></p><p>SSD:</p><p>- Nein die SSDs benötigst du für den WBC bei Parity. Bedeutet, dass Daten zunächst auf die SSDs gelegt werden und anschließend auf die Festplatten kopiert werden. Deutlicher Schreibgeschwindigkeitsgewinn. Beim Lesen keine Vorteile (anders als bei Tiering, da hier häufig verwendete Daten auf den SSDs liegen bleiben).</p><p></p><p>Live TV/Aufnahmespeicher:</p><p>- Ich gehe davon aus, dass du bei Live-TV Timeshift meinst? Falls ja dann würde ich den in den RAM legen bzw. da kümmert sich ja der Client und nicht der Server - dort würde es aber auch im RAM liegen, da ansonsten die SSDs doch sehr viel pro Tag schreiben würden, was sich auf die Lebenszeit auswirkt. Aufnahmespeicher geht entweder direkt auf die Festplatten oder auf den Parity Pool und somit über den WBC über die SSDs - hier lässt es sich dann nicht verhindern. Je nach dem wie viel aufgenommen wird, bedeutet das einen regelmäßigen Austausch der SSDs.</p><p></p><p>Seagate Archive:</p><p>- Zur Zeit benutze ich bei meinen Tests ausschließlich 2TB WD Green, also auch Festplatten die für RAID eher ungeeignet sind. Mir wäre aber noch nicht aufgefallen, dass Storage Spaces sich hier aus dem Takt bringen lässt. Der Timeout kommt ja meist vom RAID-Controller. Mit Storage Spaces (wie bei LVM unter Ubuntu) kann man das ganze ja sogar über langsame USB 2.0 Werbesticks betreiben (zum testen natürlich).</p><p>Sollte also kein Problem sein (ich plane die selben HDDs, da sie P/L technisch nicht Schlagbar sind, wobei mir WD HDDs lieber sind... aber hier werden ja irgendwie keine veröffentlicht).</p><p></p><p>Installation:</p><p>- Die Installation des ESXi kommt auf einen USB-Stick (wird beim booten ohnehin alles im RAM abgelegt). Und die Installation vom Windows Server kommt auf eine SSD mit den anderen VM's auch. Die HDDs für den Pool werden dann durchgemountet.</p><p>Die Grundinstallation liegt somit niemals mit im Pool - das ist nicht machbar und von Microsoft auch nicht vorgesehen.</p><p></p><p>Neuinstallation/Defekt:</p><p>- Das ist zur Zeit noch genau mein Gedankengang mit dem ich Probleme habe und was ich nachstellen muss - ist allerdings etwas aufwendiger. Ich hoffe das es sich so verhält, bin mir aber nicht sicher. Momentan ist der Punkt Desaster Recovery einer der größten auf meiner Liste der Negativ Punkte. So einfach, wie bei normal verwendeten Festplatten wird es vermutlich nicht sein. Bei MB defekt muss man ja Windows Typisch häufig mit einer Neuinstallation rechnen und selbst ohne bin ich mir nicht sicher, wenn es dann unterschiedliche/andere Controller sind wie davor bzw. die HDDs neue IDs erhalten, ob der Zusammenhang einfach erkannt wird - Bei einem Unix Softwareraid funktioniert das, da hier am Anfang der HDD immer ein paar Infos gespeichert werden (quasi RAID ID und ID im RAID).</p><p>Ein richtiges Recovery habe ich allerdings noch nicht getestet und ich weiß auch noch nicht ob ich das testen können werde (zumindest nicht mit Hardwaretausch, da mir das 2. alte MB fehlt - Wenn die neue Hardware irgendwann einmal kommt, kann ich es testen aber das dauert).</p><p></p><p>Gruß</p></blockquote><p></p>
[QUOTE="knuddelbaer1989, post: 1174018, member: 108341"] Meines Wissens kann Storage Spaces nur "Mirror", "Parity" und "Simple" und keine doppelte Parity wie bei RAID 6. (Es kann aber auch sein das ich hier noch auf dem Stand von Server 2008 R2 bin. Storage Spaces werden ja konsequent weiterentwickelt.) [URL]https://technet.microsoft.com/de-de/library/hh831739.aspx?f=255&MSPPError=-2147217396[/URL] Das einfach weiterwachsen ist leider auch nur in der Theorie so... Was ich bisher gelesen habe, funktioniert das nur bedingt so. Einfach kleinere gegen größere Austauschen gehört auch nicht so ganz zum Konzept. Neue hin zustecken schon eher. Hier hängt das allerdings stark von den Columns ab, wie sie auf den Festplatten verteilt sind. Wenn du den Pool über Powershell anlegst hast du hier Einfluss drauf, ansonsten nicht. Umso höher die Columns umso schneller das Raid aber umso schwerer zu erweitern. Beim Spiegeln verhält es sich so, dass immer im gleichen Maße aufgestockt werden muss. Heißt man verwendet 6 Festplatten im Spiegel und muss dann, wenn man es erweitern will, erneut 6 Festplatten dazu stecken. [URL]http://www.miru.ch/why-column-size-does-matter-with-storage-spaces/[/URL] Ich gehe davon aus, dass es sich bei Parity ähnlich verhält, man findet hierzu allerdings nicht allzu viele Infos. Nur bei "Simple" ist das einfache erweitern möglich, da es ich hier ja auch nur im eine Art JBOD handelt und der neue Speicher einfach hinten angehängt wird. Ich persönlich bin mir, umso mehr ich mich damit beschäftige, immer unsicherer ob es Storage Spaces werden oder ob ich es mache wie bisher (Festplatten in Ordner mounten, damit ich bei MpTVSeries oder Moving Pictures nur einen Laufwerksbuchstaben angeben muss). Der Vorteil der Fehlersicherheit teilt sich den Nachteil mit der Komplexität und dem erschwerten Desaster Recovery. Bei meinem Momentanen Aufbau habe ich den Vorteil, dass wenn mein HTPC (dort sind zur Zeit alle Platten drin) den Geist aufgibt, ich einfach die HDDs in einen anderen Rechner hängen kann und dort alles auslesen kann. Ob das mit Storage Spaces so funktioniert bezweifle ich einfach mal und da ich auch kein Backup aller Daten machen werde (Bilder/Privates/Persönliches sind mehrfach gebackupt aber Aufnahmen und dergleichen sind mir nicht wichtig genug um einen 2. Server zu bertreiben der die selbe Kapazität vorweist). Dann zu den Fragen SSD: - Nein die SSDs benötigst du für den WBC bei Parity. Bedeutet, dass Daten zunächst auf die SSDs gelegt werden und anschließend auf die Festplatten kopiert werden. Deutlicher Schreibgeschwindigkeitsgewinn. Beim Lesen keine Vorteile (anders als bei Tiering, da hier häufig verwendete Daten auf den SSDs liegen bleiben). Live TV/Aufnahmespeicher: - Ich gehe davon aus, dass du bei Live-TV Timeshift meinst? Falls ja dann würde ich den in den RAM legen bzw. da kümmert sich ja der Client und nicht der Server - dort würde es aber auch im RAM liegen, da ansonsten die SSDs doch sehr viel pro Tag schreiben würden, was sich auf die Lebenszeit auswirkt. Aufnahmespeicher geht entweder direkt auf die Festplatten oder auf den Parity Pool und somit über den WBC über die SSDs - hier lässt es sich dann nicht verhindern. Je nach dem wie viel aufgenommen wird, bedeutet das einen regelmäßigen Austausch der SSDs. Seagate Archive: - Zur Zeit benutze ich bei meinen Tests ausschließlich 2TB WD Green, also auch Festplatten die für RAID eher ungeeignet sind. Mir wäre aber noch nicht aufgefallen, dass Storage Spaces sich hier aus dem Takt bringen lässt. Der Timeout kommt ja meist vom RAID-Controller. Mit Storage Spaces (wie bei LVM unter Ubuntu) kann man das ganze ja sogar über langsame USB 2.0 Werbesticks betreiben (zum testen natürlich). Sollte also kein Problem sein (ich plane die selben HDDs, da sie P/L technisch nicht Schlagbar sind, wobei mir WD HDDs lieber sind... aber hier werden ja irgendwie keine veröffentlicht). Installation: - Die Installation des ESXi kommt auf einen USB-Stick (wird beim booten ohnehin alles im RAM abgelegt). Und die Installation vom Windows Server kommt auf eine SSD mit den anderen VM's auch. Die HDDs für den Pool werden dann durchgemountet. Die Grundinstallation liegt somit niemals mit im Pool - das ist nicht machbar und von Microsoft auch nicht vorgesehen. Neuinstallation/Defekt: - Das ist zur Zeit noch genau mein Gedankengang mit dem ich Probleme habe und was ich nachstellen muss - ist allerdings etwas aufwendiger. Ich hoffe das es sich so verhält, bin mir aber nicht sicher. Momentan ist der Punkt Desaster Recovery einer der größten auf meiner Liste der Negativ Punkte. So einfach, wie bei normal verwendeten Festplatten wird es vermutlich nicht sein. Bei MB defekt muss man ja Windows Typisch häufig mit einer Neuinstallation rechnen und selbst ohne bin ich mir nicht sicher, wenn es dann unterschiedliche/andere Controller sind wie davor bzw. die HDDs neue IDs erhalten, ob der Zusammenhang einfach erkannt wird - Bei einem Unix Softwareraid funktioniert das, da hier am Anfang der HDD immer ein paar Infos gespeichert werden (quasi RAID ID und ID im RAID). Ein richtiges Recovery habe ich allerdings noch nicht getestet und ich weiß auch noch nicht ob ich das testen können werde (zumindest nicht mit Hardwaretausch, da mir das 2. alte MB fehlt - Wenn die neue Hardware irgendwann einmal kommt, kann ich es testen aber das dauert). Gruß [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Language specific support
Deutsches MediaPortal Forum
Hard- und Software rund um den HTPC
Hardware
Mainboards/CPU/RAM
Neuer TV-Server mit speziellen Anforderungen
Contact us
RSS
Top
Bottom