[Kaufberatung] NAS als Backuptarget

Toupman

Enthusiast
Thread Starter
Mitglied seit
10.01.2005
Beiträge
199
Ort
Arzfeld
Hallo,

Aktuell mache ich die Veeam Backups meines Hauptsystems und von drei Clients auf mein per iSCSI Target eingebundenen QNAP 412.

Die Performance ist nicht so prall. Ich komme auf ca. 20-21MB/s.

Um das ganze zu verbessern denke ich, dass das QNAP weichen muss. Die 4x2TB WD RED aus dem QNAP würde ich gerne behalten.

Aktuell suche ich nach Hardware. Ein 19“ Gehäuse hab ich noch. Netzteil könnte noch gut sein, dass muss ich mir aber noch genauer anschauen.

Was mir fehlt sind:

Mainboard

CPU

RAM

RAIDcontroller? (Eventuelle gebraucht?)



Das System soll nachher eine ordentliche Backup Performance bieten. Nicht mehr und auch nicht weniger.

Was würdet ihr da vorschlagen?

Mit freundlichen Grüßen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich denke über die Hardware bin ich mir jetzt im klaren.

Allerdings kommt jetzt die Frage auf welches OS soll ich einsetzen um möglicht lean und performant ein iSCSI Target bereit zu stellen.
Auf dieses iSCSI Target läuft die VEEAM Sicherung der VM's, ein Windows Image Backup des Host bei Änderungen und die Backups der Clients über ein vom Server bereitgestelltes Share auf dem iSCSI Target.
Auf dem Server läuft Windows Server 2016 als Hyper-V Host und die Clients sind alle Windows 10.
Das System soll möglichst wartungsarm sein.
Zudem bin ich nicht ganz so fit was Linux angeht, habe aber schon mehr als einmal eine Shell gesehen ;-)


Was könnt ihr da für Betriebssysteme empfehlen?
 
...auch auf die Gefahr endgültig als langweilig und Fanboi dazustehen: solarish+napp-it.
 
Warum iSCSI?
Veeam kann auch auf SMB-Shares sichern, daher kann ich keinen Grund für den iSCSI Protokolloverhead sehen.

NAS4free ist auch ganz nett, je nach Gusto kann mana uch FreeNAS oder OMV nehmen.
 
Das mit dem Protokolloverhead war mir so nicht bewusst, dann stell ich das auf SMB um.

Gelten für SMB die gleichen Software Empfehlungen?
 
iSCSI Protokolloverhead. Nee, wenn das langsam ist, ist die Hardware nicht potent genug. Meine Backups auf Arbeit gehen auf das selbe NAS per iSCSI ca 30% schneller als auf NFS und 35-40% schneller als auf SMB.
 
Performanceunterschiede zwischen den Protokollen sollten eher geringer sein. Für die Entscheidung für ein Protokoll ist aber anderes auschlaggebend

iSCSI: Damit wird EINEM Arbeitsplatz Netzwerkspeicher als lokale Platte angeboten.
Ideal wenn eine Anwendung eine lokale Platte möchte oder aber wenn man das lokale Dateisystem z.B. ntfs braucht.

NFS: Ein Multiuser Netzwerk Dateisystem vor allem für Unix/ Linux/ ESXi Gäste
Ideal vor allem wenn man Performance in einem sicheren Netz möchte (NFS3)

SMB: Ein Multiuser Service der die meisten Features bietet, vor allem wenn man Authentifizierung und Authorisierung möchte.


Wenn man mehr als 5s braucht um sich zu entscheiden, ist sicher SMB die beste Wahl.
 
Also das RAID von dem gelesen wird ist ein RAID 5 mit 4 Platten HP 2TB 3G SATA 7.2K 3.5" MDL HDD an einem Smart Array P410 mit 1GB Cache, Prozessor Xeon E3-1245v5 und 16 GB DDR4 ECC RAM.
Das QNAP hat einen Marvell 6281 1.2GHz und 256 MB RAM mit einem RAID 5 über vier WD RED 2TB.

Also muss es eigentlich am QNAP liegen.

Eine Hardwarefrage habe ich aber noch:

Ich hab mir als CPU den Pentium G4560 rausgesucht. Dazu 4GB DDR4 ECC RAM.
Beim Board bin ich mir aber noch nicht sicher.

Zur Auswahl stehen:

  1. MSI E3 Krait Gaming V5
  2. Fujitsu D3417-B2/D3417-B21

Das MSI ist halt 60€ günstiger, hat ECC RAM und einen ordentlichen Chipsatz.

Kennt jemand das Board?
 
Hi!

das Fujitsu ist ein echtes Stromsparwunder. ECC Ram ist definitiv kein Fehler.

Eine andere Variante ist das Supermicro X11SSL-F.
Höherer Stromverbrauch und etwas teurer;
2. GB Intel Nic (höhere Bandbreite bei Multiclientzugriff wenn das Raid das hergibt)
IPMI Nic inkl. Remote KVM, etc. (Der Server kann Headless betrieben werden)

lg

Lolli
 
Zuletzt bearbeitet:
Hallo,

mein Projekt geht jetzt in die nächste Runde.

Dazu ich mir habe gedacht, wenn ich schon was eigenes zusammenbaue, dann kann es auch ruhig was gebrauchtes sein.

Folgendes gab es über E-Bay, bzw. E-Bay Kleinanzeigen:

Mainboard: ASUS P9D-MH/SAS/10G-DUAL für 99€, ,noch nie benutzt nur einmal den Karton geöffnet
CPU: Intel i3 4170 gebraucht für 60 €
RAM: Kingston ValueRAM DIMM Kit 4x4GB DDR3 1333 CL9 ECC gebraucht für 40€
Netzteil: Thermaltake Munich 430W

In meiner Gerümpelkiste habe ich dann noch folgende Komponenten gefunden:

HP SmartArray P812 Controller samt 1GB Flash Backed Cache und extension card
HP NC364T PCI Express Quad Port Gigabit Server Adapter
CableDeconn Internal Mini SAS 36Pin (SFF-8087) Male To 4 SATA 7Pin with Latch Forward Breakout Kable

Vom alten NAS übernehme ich die vier SATA HDDs Samsung HD204ui.

Was mir noch fehlt ist ein Medium für das OS und die Entscheidung was ich für ein OS installiere.

Das Asus Board hat einen LSI 2308 SAS Controller on board. Allerdings kann der nur Raid 1, 0 und 10. Von daher habe ich an den HP gedacht, den ich noch da liegen hab.

Zumindest bei Windows Server als OS würde ich wohl den HP nehmen und ein RAID 5 über die vier Platten machen.

Es juckt mich aber schon sehr mal was in Richtung ZFS (napp-it) auszuprobieren. Geht das überhaupt gut mit der vorhandenen Hardware? Ich wollte eigentlich nichts mehr zusätzlich investieren, wenn es nicht sein muss.

Was würdet Ihr mit dem Kram machen, wenn Ihr es nutzen müsstet?
 
Das Mainboard ist mal ein geiler Schnapper für den Preis! CPU und RAM reicht für einen reine Filer/NAS. Zum Netzteil enthalte ich mich (das wechselt sich sowieso alle Nase lang ab).

Wunderbar für ZFS geeignet - genauer sogar IDEAL!
Flash LSI 2308 to IT-mode on a SuperMicro X10SL7-F mainboard Widodh

den P812 kannst du dann wieder in Grabbelkiste legen (Für Windows wäre der allerdings vorzuziehen!)

ich würde noch ein ASUS ASMB7-IKVM, IPMI 2.0 Management Upgrade Kit with KVM (90SC0400-M0UAY0) | heise online Preisvergleich / Deutschland nachkaufen, dann hast du vollen Headlessbetrieb (BIOS, Bootvorgang, Konsole)

die HP NC364T kannst du eigentlich auch wieder wegpacken, das Board hat 2x 10 GBE (SPF+), 2x Gbit Plus 1 Managementport
Für die SPF+ Anschlüsse bräuchtest du vermutlich noch 2 Transceiver (auf Twistetpair), sofern SFP(+) nicht schon anderweitig vorhanden ist.
(wäre natürlich ein idealer Zeitpunkt um über eine allgemeine Aufrüstung auf 10GBE nachzudenken bzw. diese zu planen)

Sofern nur Stroage geplant ist, wäre meine Reihenfolge:

Solaris basiert (natives ZFS):
Solaris/Napp-IT
OmniOS/Napp-IT
(Openindiana/Napp-IT)
+ CIFS / SMB native im Kernel, daher zu Windows am kompatibelsten und schneller als die FreeBSD Varianten


FreeBSD basiert (natives ZFS):
NAS4Free
FreeNAS
(TruOS - ist ein vollwertiger Fork von FreeBSD mit verstärktem Focus auf ZFS ohne aber an den Verwaltungskomfort von FreeNAs/N4F heranzukommen -ist halt mehr "Old School")

Linux basiert (ZoL):
OMV
(Debian, Ubuntu usw.)
 
So, der Rechner ist zusammengebuat und läuft :hail:

Solaris ist auch schon installiert, aber mit Napp-It habe ich so meine Probleme...

Wenn ich den Befehl so eingebe wie in der Anleitung erhalte ich folgende Meldung:
Code:
 wget -O -www.napp-it.org/nappit | perl
wget: URL fehlt
Syntax: wget [OPTION]... [URL]...

»wget --help« gibt weitere Informationen.

Deshalb habe ich jetzt folgenden Befehl genutzt:

Code:
root@SolBackup:~# wget -O -URL www.napp-it.org/nappit | perl
--2018-02-27 12:45:45--  http://www.napp-it.org/nappit
Auflösen des Hostnamen »www.napp-it.org (www.napp-it.org)«... 188.93.13.227, 2a00:1158:1000:300::368
Verbindungsaufbau zu www.napp-it.org (www.napp-it.org)|188.93.13.227|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43076 (42K)
In »»-URL«« speichern.

-URL                100%[=====================>]  42,07K  --.-KB/s   in 0s

2018-02-27 12:45:45 (128 MB/s) - »»-URL«« gespeichert [43076/43076]

Und dann passiert genau nichts, auch nach einem Reboot antwortet der Server nicht auf Port 81.

Was habe ich falsch gemacht?
 
Der erste Befehl ist prinzipiell korrekt, aber Du hast kein Leerzeichen zwischen - und www. Sobald du dort ein Leerzeichen einfügst, wird der Befehl funktionieren.
-O- bedeutet Ausgabe des Inhalts auf STDOUT, wo der Perl Interpreter das dann über die Pipe liest
Wie Du es schreibst, sieht er -www... als Parameter an.
Im zweiten Fall lädt er den Inhalt korrekt herunter, speichert ihn aber in der Textdatei "-URL" statt ihn an Perl zu übergeben.

Also einfach folgenden Befehl nutzen:
Code:
wget -O - www.napp-it.org/nappit | perl

Edit: Sobald Du den Befehl richtig eingegeben hast, wirst Du auch sehen, dass sich im Anschluss etwas tut. Je nach Leitung kann das zwischen Minuten und einer halben Stunde dauern.
 
Zuletzt bearbeitet:
Der aktuelle Stand ist, dass Napp-IT schon zweimal installiert wurde.

Zuerst unter Solaris 11.3 und jetzt unter 11.4 Beta.

Ich bin sehr zufrieden mit dem System und meine Test mit und ohne Deduplicaiton sind sehr erfreulich verlaufen.

Drei Fragen habe ich aber noch dazu:

  1. Irgendwie geht der Nameserver immer wieder verloren. Wenn ich den in der Console neu eintrage geht es kurz und einige Minuten später nicht mehr. Das ist aufgefallen, als ich TLS Mails nachinstallieren wollte. Woran kann das liegen?
  2. Wie macht man eine Link Aggregation der Netzwerkkarten unter Solaris?
  3. Ich habe die Deduplication für ein ZFS von zweien (ClientBackup und ServerBackup) eingeschaltet. Allerdings habe ich irgendwo gelesen, dass die Einstellung immer für den ganzen Pool gilt. Stimmt das so?

MfG

Tobias
 
Zuletzt bearbeitet:
Punkt eins ist erledigt. Der Nameserver bleibt immer drin stehen. Aber obwohl ein nslookup auf pkg.oracle.com erfolgreich ist, erhalte ich immer folgende Fehlermeldung:

Code:
root@SolBackup:~# pkg install net-ssleay
Creating Plan (Finding local manifests): \

Errors were encountered while attempting to retrieve package or file data for
the requested operation.
Details follow:

pkg://solaris/library/perl-5/net-ssleay-522@1.80,5.11-11.4.0.0.0.12.0:20180103T031742Z
  Framework error: code: E_MULTI_UNKNOWN_OPTION (6) reason: Couldn't resolve host 'pkg.oracle.com'
URL: 'https://pkg.oracle.com/solaris/beta/manifest/0/library%2Fperl-5%2Fnet-ssleay-522@1.80%2C5.11-11.4.0.0.0.12.0%3A20180103T031742Z' (happened 4 times)

Sehr seltsam.

Punkt zwei ist fast erledigt. Ich habe es geschafft eine Linkaggregation anzulegen, aber diese zeigt weiterhin als Speed 1000Mb full und wenn ich mit zwei Clients gleichzeitig auf unterschiedliche Shares kopiere, komme ich auch nie über 1000Mb.
2018-03-06_14-52-48.png

Woran kann das noch liegen?
 
1. Eventuell ist das Repo nicht unlocked
(Man braucht einen SSL Key für Solaris)

net-ssleay-522@1.80,5.11-11.4 weist auch darauf hin, dass das Repo für Solaris 11.4 ist

2.Die Aggregation zeigt immer die Performance der Links an.
Wenn zwei Cliients gleichzeitig kopieren, so könnte lediglich jeder max 1G erhalten (sofern die Aggregation nicht auf Failover steht).

Ohne Aggregation müssten sich beiden die 1G teilen.
 
1) Doch das Repo ist unlocked. Ich habe ja mit den gleichen Einstellungen den gcc-5 und den storage-server installiert. Ich werde mal einen anderen Netzzugang testen. Nicht das unsere FW irgendwas blockt.

2) Das ist mir bewußt, aber leider haben beide kumuliert nur 1G erreicht. In der Napp-IT Oberfläche wird dann auch die Statusanzeige bei NET rot und darunter sieht man dann einen Auslastung von 100% bei 989 Mbit/s. Aber da müsste das Maximum doch dann bei 2000 Mbit/s liegen, oder?
 
Dann muss ich mir iperf mal anschauen. Das habe ich noch nie benutzt. Aber man macht sowas ja auch um etwas zu lernen.
 
napp-it Menü Services > Iperf Server
auf anderer Maschine einen Client starten (System > Network Eth > Iperf Client )

Iperf muss aber installiert sein (pkg install iperf)
 
Zuletzt bearbeitet:
Gut, dann muss ich erstmal das Problem der Packetinstallation lösen.

Code:
root@SolBackup:~# pkg install iperf
No updates necessary for this image.


WARNING: Errors were encountered when attempting to retrieve package
catalog information. Packages added to the affected publisher repositories since
the last retrieval may not be available.

Errors were encountered when attempting to contact repository for publisher 'solaris'.

Unable to contact valid package repository: https://pkg.oracle.com/solaris/beta/
Encountered the following error(s):
  Framework error: code: E_MULTI_UNKNOWN_OPTION (6) reason: Couldn't resolve host 'pkg.oracle.com'
URL: 'https://pkg.oracle.com/solaris/beta' (happened 4 times)
 
Ja, damit muss es irgendwas zu tun haben:

Code:
root@SolBackup:~# ping www.google.de
ping: unknown host www.google.de
root@SolBackup:~# nslookup www.google.de
Server:         10.83.134.1
Address:        10.83.134.1#53

Non-authoritative answer:
Name:   www.google.de
Address: 172.217.18.163

Ich schmeiß jetzt mal alles aus der resolv.conf raus außer 8.8.8.8

- - - Updated - - -

Ich versteh es nicht mehr...

Code:
root@SolBackup:~# nslookup pkg.oracle.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
pkg.oracle.com  canonical name = pkg.oraclegha.com.
Name:   pkg.oraclegha.com
Address: 137.254.56.18

root@SolBackup:~# pkg install iperf
No updates necessary for this image.


WARNING: Errors were encountered when attempting to retrieve package
catalog information. Packages added to the affected publisher repositories since
the last retrieval may not be available.

Errors were encountered when attempting to contact repository for publisher 'solaris'.

Unable to contact valid package repository: https://pkg.oracle.com/solaris/beta/
Encountered the following error(s):
  Framework error: code: E_MULTI_UNKNOWN_OPTION (6) reason: Couldn't resolve host 'pkg.oracle.com'
URL: 'https://pkg.oracle.com/solaris/beta' (happened 4 times)

- - - Updated - - -

Jetzt hab ich mir das soweit kaputt gespielt, dass noch nicht mal mehr ein Publisher drin steht und ich kann auch keinen neuen mehr eintragen :bigok:

Morgen gehts an einem reinen DSL Anschluss ohne alles weiter.
 
Das Problem der zu installierenden Pakete liegt effektiv an unserer Firewall an dem alten 2MBit SDSL läuft alles sauber.

Allerdings zeigt er bei PKG install iperf nur an: Für dieses Abbild sind keine Updates erforderlich.
Sonst passiert nichts. Bei net-ssleay werden sauber die 2 Pakete installiert.

- - - Updated - - -

Muss für Solaris 11.4 beta auch die SSL.pm getauscht werden?
Und wo kann ich den Port ändern?
 
Also, ich habe napp-it ebenfalls auf Solaris 11.4 installiert und die einzig außerplanmäßige Aktion ist, das Beta Repo vor napp-it zu installieren. Dann muss man auch weder einen Compiler noch den storage Server von Hand installieren.
Wenn keine Updates verfügbar sind, sollte iperf bereits installiert sein?!?
Oder Du hast Deinen Paketmanager komplett kaputtgespielt. Versuch nochmal die Anleitung von der Solaris Beta Repo Seite.

Edit: wieso willst Du eigentlich auch(? Wieso auch?) die SSL.pm tauschen?
Der Port 81 ist soweit ich gesehen habe hardcoded.
 
Zuletzt bearbeitet:
Oh, sorry da hab ich mich etwas falsch ausgedrückt in der Hektik.

Also mit dem Port meinte ich den TLS Port. Aber ich habe jetzt von t-online auf googlemail gewechselt und das funktioniert einwandfrei.

Das mit der SSL.pm hatte ich aus der Anleitung von der napp-it Seite.

Mit dem iperf habe ich das Problem das es nicht installiert ist. Mit pkg uninstall iperf sagt er das das Paket nicht installiert ist und mit pkg install iperf sagt er Für dieses Abbild sind keine Updates erforderlich.

Sehr seltsam...
 
Versuch mal tree zu installieren, das hatte ich nachinstalliert, glaube ich. Das hat damit zwar nichts zu tun, nur um zu sehen, ob überhaupt noch was installiert wird.
Was spricht denn pkg update?
Gibt es irgendwann Fehler, wenn du die Anleitung von der Solaris Beta Repo Seite ausführst?
 
Also ich habe net-ssleay erfolgreich installiert. Von daher müsste ja alles mit dem repo passen. Pkg update muss ich dann morgen mal testen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh