Vor allem weil in der Leistungsbeschreibung steht, dass dort noch garkein Vlan geht.
Böse Zungen könnten behaupten, dass das um 21 Uhr noch anders geplant war. 
Aber egal, Hauptsache es funktioniert am Standort Nürnberg wieder. Das ist das Wichtigste, da sind wir uns wohl alle einig? 
Verfügen die Root Server am Standort Wien über die gleichen Features, wie jene am Standort Nürnberg?
Ja, die Root Server am Standort Wien verfügen über alle Features wie jenen Root Server am Standort Nürnberg, mit Ausnahme von Failover IPs und CloudVLAN. Diese beiden Features werden in Kürze zur Verfügung stehen.
[netcup] Claudia H. [netcup] Christina R. Ist schon absehbar was mit "in Kürze" gemeint ist?
Einige Wochen bis Monate oder ist das ein langfristiges Projekt, mit dem man nicht vor Quartal XYZ rechnen sollte?
Vienna, Vienna!
*sabberlechzstöhn*
Ob der gestrigen Ausfall der VLANs mit dem neuen Standort VIE zusammenhängt? 
Ist da eventuell irgendwas beim Zusammenschalten schief gelaufen? 
Jein, nur ein Teil der angebundenen Server sind darüber erreichbar. Ca. 50/50 würde ich schätzen.
Korrektur: Jetzt sind alle wieder online
Also mein VXLAN tut wieder was es soll. Könnt ihr das auch bestätigen?
Jein, nur ein Teil der angebundenen Server sind darüber erreichbar. Ca. 50/50 würde ich schätzen.
Tja, Störungen haben manchmal auch positive Nebeneffekte. 
Welcome back Mainboarder 
Hat schon jemand den Notfallsupport kontaktiert bezüglich vLAN?
Hat hier noch irgendjemand Probleme mit seinem Cloud vLAN?
Bei mir ist plötzlich keine Verbindung mehr im vLAN möglich. Totalausfall 
Falls es irgendwen interessiert…
Spricht eigentlich irgendwas dagegen, ZFS-Snapshots an einen ZFS-Pool zu senden, der über iSCSI eingebunden wird?
Bei Tests (simulierte Unterbrechung der Verbindung zum iSCSI-Target) habe ich es gerade geschafft, dass ZFS komplett hängt. Letzten Endes hat nur noch ein Reboot geholfen, der allerdings deutlich mehr als 10 Minuten gebraucht hat.
Keine Ahnung, wie ich das geschafft habe. Bei vorherigen Tests hat sich der iSCSI-Initiator bzw. ZFS eigentlich immer von alleine erholt, spätestens wenn das iSCSI-Target wieder verfügbar war. Das war gerade eben nicht der Fall. Immerhin sind die ZFS-Pools intakt, die haben es problemlos überlebt.
Ich bleibe dann wohl lieber bei einer normalen und erprobten Backupstrategie, ohne iSCSI dazwischen. Die Snapshots kann ich ja trotzdem lokal vorhalten und irgendwo hin senden, aber eher nicht über iSCSI. Das ist mir zu kritisch, wenn das unbeaufsichtigt läuft…
Weshalb zum Geier will man mit dd Clonen und damit nicht nur jede Menge unbelegte Bits, sondern auch noch jede Fragmentation und jeden Dateisystemfehler mit kopieren?
Prinzipiell berechtigter Einwand. Es kommt aber auch darauf an, was bzw. wie viel auf der Platte liegt und wie schnell es gehen muss. Wenn es sich z.B. um Millionen kleine Dateien handelt, ist dd oftmals effektiver.
An dieser Stelle übrigens ein kleines Codebeispiel, wie man mittels "Process Substitution" im gleichen Durchgang eine Prüfsumme berechnen kann, um sie nach dem Kopieren nochmals abzugleichen:
# Speichert den Hash in einer eigenen Datei und kopiert die Eingabedatei gleichzeitig...
dd if=/tmp/input | tee >(sha512sum | cut -d ' ' -f 1 > /tmp/sha512sum) | dd of=/tmp/test-file
# Macht das gleiche, aber zeigt Dir den Hash stattdessen auf STDERR an...
dd if=/tmp/input | tee >(sha512sum | cut -d ' ' -f 1 >&2) | dd of=/tmp/test-fileDas hatte ich, letztes oder vorletztes Jahr, mit einem anderen Kunden mal probiert. Da gab es nur die Antwort das man mir nicht antworten dürfte.
Aber ich werde das heute mal wieder probieren, vielleicht hat sich das geändert oder ich hatte letztes Mal einfach nur pech.
Ich mache das schon seit zig Jahren so bei meinem eigenen Account. Hinterlegt ist nämlich nur meine GMX-Adresse, ich antworte dann immer vom eigenen Mailserver bzw. Domain.
Siehe auch mein Edit, vielleicht ist das die Ursache:
(Ob die Ticketnummer im Betreff ausreicht oder auch die In-Reply-To bzw. References Header stimmen müssen weiß ich allerdings nicht.)
So genau kenne ich das verwendete Ticketsystem leider nicht, um zu wissen, wie das intern ohne Modifikationen arbeitet.
https://www.netcup.de/bestellen/produkt.php?produkt=2826 20€ für ein Notizbuch?
War zu Ostern auch nicht günstiger. Wenn ich mich an meine damalige Recherche richtig erinnern kann, ist das im Einkauf wahrlich nicht billig. Und die Versandkostenpauschale (nicht nur DE!) ist ja auch noch einkalkuliert.
Würde ich allerdings trotzdem nicht kaufen. Meines von Weihnachten liegt noch unbenutzt herum, das traut man sich ja fast gar nicht verschreiben.
Caspar Der Kunde soll Dir die erste Antwort von netcup weiterleiten, im Idealfall vielleicht als Anhang. Von wo man selbst auf bestehende Tickets antwortet scheint netcup nämlich egal zu sein. Das funktioniert normalerweise problemlos und alle Beteiligten landen im Ticketsystem automatisch im CC. 
(Ob die Ticketnummer im Betreff ausreicht oder auch die In-Reply-To bzw. References Header stimmen müssen weiß ich allerdings nicht.)
Blöd ist halt trotzdem, dass das Ticket durch den Kunden im CCP oder von der richtigen E-Mail Adresse aus erstellt werden muss…
Zack Zugangsdaten zum CCP & einem Server gefunden...
Da will doch nur jemand testen, wie zuverlässig 2FA ist.
[…] Was es schwierig macht, ist die fehlende Unterstützung oder mangelhafte Umsetzung vor allem in vielen SoHo Produkten. Das ist dann gefühlte Mehrbelastung, das kann man aber kaum dem Standard anlasten. Ich möchte IPv6 nicht mehr missen.
Wen die Schuld trifft, ist dem normalen Endanwender in der Regel aber egal.
Ich möchte es auch nicht mehr missen, nicht umsonst habe ich jahrelang einen eigenen 6in4-Tunnelserver betrieben und den Internetprovider u.a. wegen der fehlenden IPv6-Unterstützung gewechselt. Dass der Standard schuld ist, behaupte ich auch gar nicht. Aber die Implementierung ist an vielen Stellen durch Hersteller von Soft-/Hardware mangelhaft oder nicht zu Ende gedacht.
Im Endeffekt wird uns IPv4 wahrscheinlich noch Jahrzehnte begleiten. Ob wir als Admins das gut oder schlecht finden spielt dabei keine Rolle. Solange nicht irgendein großer Dienst IPv4 abdreht, wird sich da nichts tun. Und das wird in absehbarer Zeit niemand machen, weil es garantiert einige Partner und Kunden vergraulen würde. Die Mehrkosten für Dualstack sind dagegen wahrscheinlich nicht der Rede wert.
Das ist ja nur die halbe Wahrheit. Mein Zeug funktioniert einfach nicht, solange das IPv6 Prefix dynamisch ist. […]
Manchmal bin ich echt froh, dass ich für interne Kommunikation immer ULA verwende. Und, dass mein DSL-IPv6-Subnetz statisch ist.
Aber prinzipiell hast Du es wirklich gut zusammengefasst: IPv6 ist an vielen Stellen immer noch ein K(r)ampf… 
Wichtig ist hier, dass die DiskStation selbst zu keinem Zeitpunkt mit einem eigenen ZFS-Treiber auf den ZFS-Pool zugreift; das sollte normalerweise der Fall sein, wenn die entsprechenden Platten/Partitionen für iSCSI-Targets verwendet werden, ich würde mich dessen aber explizit im Vorfeld versichern.
Die Synology Geräte können sowieso nicht mit ZFS umgehen
Wenn hier nochmal eine ext4-Schicht dazwischen liegt (Nutzung virtueller Blockgeräte), ist das natürlich ein Unterschied, welcher nochmals den Durchsatz negativ beeinflusst. Bleibt immer noch machbar, viel umständlicher (=mehr Overhead) geht dann aber auch nicht mehr.
Der Durchsatz ist mir ehrlich gesagt ziemlich egal. Der Reiz daran wäre halt, dass ich relativ flexibel bin. Und für eine private Spielerei ohne professionelle Ansprüche wäre es ganz interessant.
Danke jedenfalls für Deine fundierte Einschätzung! 
Was auf jeden Fall fix ist, unabhängig von der ZFS-Thematik: Mit iSCSI spiele ich mich weiter herum. Da steht eigentlich schon seit Jahren auf meiner TODO-Liste...
Fein, dass es wieder geht.
Naja, final gelöst ist es noch nicht. Die Pakete nehmen nun halt vorübergehend einen anderen Weg
[…] laut meinem Provider war das Problem seit Freitag bekannt ... und am Montag früh waren immer noch Probleme. […] Bitte das nächste mal da eine Meldung machen, damit das Wochenende auch ein solches bleiben kann.
Ich habe das Problem jedenfalls erst am Sonntag an netcup gemeldet. Mit fonira hatte ich keinen Kontakt diesbezüglich, weil ich den Fehler ursprünglich eher bei netcup vermutet habe. Allzu viele Leute dürften es auch nicht bemerkt haben, sonst hätte es z.B. im LTEForum schon einen kleinen Aufschrei gegeben, wo sich viele fonira-Kunden aufhalten.
Wenn es einem der beiden Beteiligten Provider bereits seit Freitag bekannt war, wäre es natürlich unschön, wenn die Kommunikation zwischen den beteiligten NOC am Wochenende nicht möglich bzw. von Erfolg gekrönt war. Aber das kann ich als Außenstehender schwer beurteilen.
PS: Wo hat fonira eine offizielle Statusseite? Kenne ich irgendwas noch nicht?
Spricht eigentlich irgendwas dagegen, ZFS-Snapshots an einen ZFS-Pool zu senden, der über iSCSI eingebunden wird? Abgesehen von der unsinnigen Tatsache, dass die LUNs auf einem ext4 in einem RAID5 liegen und das iSCSI-Target keinen ECC-RAM hat.
Target: Synology DiskStation (DSM)
Initiator: Proxmox VE (Debian)
Ich würde dann im Bedarfsfall am Proxmox-Server einfach so vorgehen:
Entstehen mir da irgendwelche Nachteile bzw. riskiere ich da irgendwas? Dass ich auch diesen Pool hin und wieder scrub'en sollte, versteht sich von selbst.
/cc m_ueberall
