Servicezuweisung greift nicht - eth1 wird für alle Dienste genutzt

    2 QNAP TS1231XU-Rp im Einsatz, Weitergehend als „erstes“ und „zweites“ bezeichnet


    Router

    nicht relevant – Subnetz hat kein Zugriff auf Internet|

    |

    Switch

    Kaskadierendes Cisco Switch-Netz, Cat6 Verkabelt, Uplinks 10 GbE SFP+, 1 GbE Ports


    NAS sind je mit 2 mal 1 GbE und 1 mal 10 GbE am Switch angeschlossen, kein Trunk, keine Jubos. Alle IP Adressen sind als feste IP Adressen in einem Subnetz auf den jeweiligen Nas fest eingetragen und im DHCP via Reservierung gegen mehrfache Nutzung geblockt.

    „erstes“ QNAP nutz eth1 x.x.x.122, eth2 x.x.x.123 sowie eth3 x.x.x.126, eth4 x.x.127

    „zweites“ QNAP nutzt eth1 x.x.x.124, eth2 x.x.x.125 sowie eth3 x.x.x.128, eth4 x.x.x.129


    „erstes“ QNAP eth4 und „zweites“ Qnap eth3 sind direkt miteinander verbunden.


    Kabellänge jeweils 5 Meter, als Kabel kommt Cat.6e bzw. LWL Glasfaser zum Einsatz. Kein WLAN oder Powerlan im Einsatz.


    Firmwareversion 4.3.4.0644 Build 20180710 – eine ältere Version einspielen ist aus verschiedenen Gründen nicht möglich


    Genutztes BS: Win 7 SP1 / Win Serv 2012 r2 Standart

    Als Datensender ist ein Blade 7000 im Einsatz, angebunden mit 1 GbE


    Hallo zusammen,

    ich habe ein Problem mit der Servicezuweisung. Folgendes Szenario liegt zugrunde: „Erstes“ QNAP stellt über einen Freigabenordner Speicherplatz bereit. Wenn auf diesen Daten geschrieben werden, sollen die Daten via RTRR Sync-Job auf das „zweite“ QNAP repliziert werden. Soweit funktioniert das auch, aber entgegen der Einstellung in der Servicezuweisung nutzt das „erste“ Qnap immer eth1 für den RTRR-Job. Die Servicezuweisung läuft auf eth3 und eth4. Dieses fehlerhafte Verhalten führt zu dem Problem das die zur verfügung stehende Bandbreite nicht genutzt werden kann - zwischendurch bricht der Datenempfang für den Datenupload ein, oder umgekehrt.


    Was wurde schon Probiert:

    Neustart der Systeme => wird immer noch nur eth1 für RTRR genutzt

    Servicezuweisung für den RTRR Job auf eth4 begrenzen => wird immer noch nur eth1 für RTRR genutzt

    Für eth4 nur RTRR in der Servicezuweisung nutzen => wird immer noch nur eth1 für RTRR genutzt

    Für eth3 nur RTRR in der Servicezuweisung nutzen => wird immer noch nur eth1 für RTRR genutzt

    Testweise ein Trunking von eth1 & eth4 einrichten und die Servicezuweisung „RTRR“ darauf binden => wird immer noch nur eth1 für RTRR genutzt

    Testweise ein Trunking von eth1 & eth3 einrichten und die Servicezuweisung „RTRR“ darauf binden => wird immer noch nur eth1 für RTRR genutzt


    Ausstehend ist jetzt noch ein neues VLAN aufzusetzten, Vermutung geht grade in die Richtung das die Servicezuweisung mit einem einzigen Gateway nicht funktioniert, da das „erste“ QNAP immer nur eth1 nutzt.


    Ich bin offen für alle Lösungen, denn ich möchte mich gerne um die interne Organisatorische Arbeit für ein neues VLAN drücken J - eigentlich muss das doch auch im selben VLAN funktionieren oder?


    Anbei 2 Screenshots zum Verständnis.


    Vielen Dank für eure Zeit :)

    Wie sind denn die RTRR-Server auf den NAS eingestellt und auf welche IP verbinden die Jobs?


    Ich habe es bei mir so gelöst, dass ich ohne Servicebindung auskomme. Ich habe für RTRR jeweils eine Schittstelle der NAS über einen eigenen Switch verbunden (bei 2 NAS nicht notwendig, können direkt verbunden werden) und diesen Schnittstellen ein eigenes Subnetz verpasst.

    Hi dr_mike,


    Ich bin mir gerade nicht sicher welche Einstellungen du im RTRR Job meinst, die Richtlinien habe ich mal angehangen. Filter sind keine gesetzt.


    Der Job verbindet vom "ersten" Qnap Soll eth4 x.x.x.127 (IST eth1 x.x.x.122) to "zweites" QNAP eth3 x.x.x.128

    Der Empfang funktioniert auch auf die richtige Schnittstelle, nur das Senden leider nicht.

    Wenn ich fragen darf: Wie hast du deinem Sendenden QNAP denn mitgeteilt welche Eth es zum Senden nutzen darf? Ich ging immer davon aus das das über die Service Bindung läuft.

    ok, an dieser Stelle habe ich bis jetzt die IP der Schnittstelle der Gegenseite eingetragen. Ich ging aus das die sendende Schnittstelle via Servicezuweisung bestimmt wird.

    Sprich die nächsten Schritte wären jetzt ein neues Subnetz aufsetzten, die IP's davon je einer Schnittstelle zuweisen und abschließend in den RTRR-Auftrag die Gateway-IP Eintragen?

    Zitat von Aschnack

    in den RTRR-Auftrag die Gateway-IP Eintragen?

    Nein, nicht die Gateway IP sondern die Ziel IP. Da diese ja im anderen Subnetz liegt, muss das NAS die Schnittstelle mit dem Subnetz nutzen.

    Der Standardgateway Eintrag bleibt bei dem Subnetz leer, da es ja zum Einen kein Gateway gibt und du zum Andern eh nur ein Standardgataway auswählen kannst. Dieses ist in deinem eigentlichen Netz und bleibt unverändert.

    dr_mike Danke das du mir hilfst - kleine Verständnisfrage - du hast nichts in der Servicebindung verändert zu den Standard settings und der RTRR-Auftrag läuft mit den 2 Subnetzen sowohl Sendend als auch Empfangend über die richtigen Schnittstellen?
    Versteh mich bitte nicht falsch, ich habe nur schon so viel Zeit in die Problemlösung gesteckt das die Lösung zu einfach scheint :) Ich möchte ja eigentlich nur das der Sync über die Direktleitung läuft....

    dr_mike thx - damit hat sich das Problem gelöst. Großes Lob für den Support, BTW. der QNAP Support bei dem ich Parallel ein Ticket offen habe hat bis jetzt seit 2 Wochen keine Lösung :)

    /closed

    Es ist halt ein Workarround, der jedoch auch Vorteile hat. Der Support versucht wohl dein Anfangsszenario umzusetzen.

    Es ist durchaus auch möglich, dass die Servicebindung an dieser Stelle wirklich ein Problem hat. Genaugenommen sollte es nämlich darüber möglich sein, dem RTRR eine Schnittstelle zuzuweisen. Insofern hat das Ticket seinen Sinn.;)