caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Hi, NIC Teaming bringt dir hier nichts - du willst ja keine Leistungssteigerung oder Ausfallsicherheit einzelner Ports erreichen sondern eine Trennung der Kommunikation (so wie ich dich verstanden habe). Eine Trennung erreicht man nur über Segmentierung und entsprechende Regeln. Wenn der Router kein SPOF sein soll, hast du dann auch redundante Switche an denen die Systeme angeschlossen sind? Ich bin noch nicht so versiert mit vLAN. Ich dachte wenn ich die NICs via Teaming oder Trunking zusammenfasse und die Clients in Subnetze einteile, könnte ich bei einer Anfrage der Clients an den DNS zur Namensauflösung des DC erreichen, dass nur die eine IP der logischen zusammengefassen NIC aufgelöst wird und nicht alle 5 anderen was ja zu Problemen mit der Verbindung führt. Anmerkung: Es handelt sich hier um eine sehr kleine Umgebung in einer Schulungsumgebung. Also hier ist keine Hochverfügbarkeit gefragt. Die Switche sind nicht reudndant ausgelegt. NIC1 auf dem Primärsrv und NIC1 auf dem Backupsrv z.B. sind mit Switch1 für Netz 192.168.102.0/24 verbunden. Weiterhin geht von diesem Switch eine Verbindung zum Router. Das ganze für 5 Netze. Router/FW hat somit auch 5 Schnittstellen. Zitieren Link zu diesem Kommentar
caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Wie syncst du den die Daten zwischen den Hosts/VMs?FT kann nur eine vCPu, da du den freien ESXi nimmst fällt das auch komplett raus. Was du da gebaut hast ist nix ganz und nix halbes. Kauf einen Router/Switch der Layer3 Routing kann, mach den als Standard GW für die Vlans und dann ACLs drauf. Für SPOF kaufst du das Ding zur Not noch mal, legst den in den Schrank und machst jeden Tag mit Rancid eine automaitsche Sicherung. Nur mal so als Lösungsansatz. Machst du DHCP auch über alle 5 Nics oder arbeitest du da wenigstens mit DHCP Relaying (was wesentlich sauberer ist meiner Meinung nach). DHCP über alle NICs - Die DHCPs sind 70/30 aufgeteilt. Welche Daten meinst du? Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 (bearbeitet) Hallo Für eine Schul(ungs)umgebung erscheint mir das Gewünschte stark überzeichnet. Ich empfehle ein Überdenken des Konzeptes. Wozu fünf physikalische Adapter? bearbeitet 12. November 2012 von lefg Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 Ich bin noch nicht so versiert mit vLAN. Ich dachte wenn ich die NICs via Teaming oder Trunking zusammenfasse und die Clients in Subnetze einteile, könnte ich bei einer Anfrage der Clients an den DNS zur Namensauflösung des DC erreichen, dass nur die eine IP der logischen zusammengefassen NIC aufgelöst wird und nicht alle 5 anderen was ja zu Problemen mit der Verbindung führt. NIC-Teaming arbeitet auf MAC-Ebene (Layer 2). Was Du willst ist ein Router (Layer 3), was Du nicht mit Teaming erreichen kannst. Beschäftige Dich ein wenig mit den Grundlagen. Du solltest Dir einen Lyer-3 Switch besorgen und Dich in die VLAN-Thematik einarbeiten. -Zahni Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 Moin, Anforderungen sind wie gesagt ein Trennung der Netze (phys.) über mehrere NICs. [/Quote] das ist keine Anforderung, sondern ein Lösungsversuch für eine Anforderung, die du immer noch nicht benannt hast. Auf diese weise reden wir nicht über eine Lösung für dein Problem, sondern über die Probleme deiner Lösung ... Die Clients aus Netz1 sollen nicht mit denen aus Netz2 kommunizieren können. Aha. Da würden wir der Sache evtl. näher kommen - wäre nur zu klären, was der Grund dafür ist. Warum sollen die Clients auf dieselben Ressourcen zugreifen können, wenn sie in unterschiedlichen Netzen sind? Oder umgekehrt: Warum sollen sie getrennt sein, wenn sie dieselben Ressourcen nutzen? Und: Was heißt "sollen nicht kommunizieren können"? Solange nicht klar ist, was inhaltlich erreicht werden soll, sollten wir keine weiteren technischen Ideen in die Runde werfen, deren Effekt nichts als eine Steigerung der Komplexität ist. Gruß, Nils Zitieren Link zu diesem Kommentar
caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Moin, das ist keine Anforderung, sondern ein Lösungsversuch für eine Anforderung, die du immer noch nicht benannt hast. Auf diese weise reden wir nicht über eine Lösung für dein Problem, sondern über die Probleme deiner Lösung ... Aha. Da würden wir der Sache evtl. näher kommen - wäre nur zu klären, was der Grund dafür ist. Warum sollen die Clients auf dieselben Ressourcen zugreifen können, wenn sie in unterschiedlichen Netzen sind? Oder umgekehrt: Warum sollen sie getrennt sein, wenn sie dieselben Ressourcen nutzen? Und: Was heißt "sollen nicht kommunizieren können"? Solange nicht klar ist, was inhaltlich erreicht werden soll, sollten wir keine weiteren technischen Ideen in die Runde werfen, deren Effekt nichts als eine Steigerung der Komplexität ist. Gruß, Nils Es gibt 5 Netze (Raum 102, 201, 205, 210, Verwaltung). Diese müssen aus sicherheits- bzw Zugriffsrechtlichen Gründen logisch getrennt werden. Jeder Raum hat einen Switch, von diesem geht eine Verbindung zu den Clients, eine zum Router und jeweils eine zum Primär und Backupserver. Ich habe in jedem physischen Server 6 Netzwerkkarten verbaut (5 für LANs, 1 Failover/Management). Es existieren 6 vSwitchte. Jedem vSwitch ist eine phyische NIC zugeordnet, sowie eine Portgruppe mit dem Namen des Netzes. Dieser Portgruppe habe ich wiederum jeweils eine virtuelle NIC von jeder VM zugewiesen, damit jede VM in jedem Netz erreichbar ist. Klappt auch alles super, bis ich das mit multihoming dc mitbekommen habe. Ich komme wohl nicht drum herum, den DC auf eine eigene VM mit nur einer NIC zu betreiben oder? Dann muss ich mit einem Layer 3 Switch und Vlan die Verbindung der Netze sicherstellen. Zitieren Link zu diesem Kommentar
nerd 28 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 Ich komme wohl nicht drum herum, den DC auf eine eigene VM mit nur einer NIC zu betreiben oder? Dann muss ich mit einem Layer 3 Switch und Vlan die Verbindung der Netze sicherstellen. richtig. Zitieren Link zu diesem Kommentar
caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Diese Lösung wird mir wohl nichts bringen, da alle LAN NICs im DNS registriert sein müssen, richtig? Probleme mit Multihomed DCs vermeiden - administrator.de Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 Wieso? Du hast dann doch nur noch eine LAN NIC. Zitieren Link zu diesem Kommentar
caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Wieso? Du hast dann doch nur noch eine LAN NIC. Mit ner VM nur für DC und nur einer NIC? Ja dann schon...ich suche eine Lösung wobei ich die jetztige Konstellation bestehen lassen kann, aber das sieht schlecht aus. Ist es denn so fatal, wenn der DC 5 LAN Schnittstellen hat? Macht sich das wirklich so stark bemerkbar (Verzögerungen)? Wie sieht es denn mit den anderen multihomed Servern aus, sind ja quasi alle anderen auch. Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 12. November 2012 Melden Teilen Geschrieben 12. November 2012 Ja.Wenn Du für die gleiche Adresse unterschiedliche IP-Adressen registrierst, macht der DNS-Server Round Robin und gibt für jede Abfrage eine andere Adresse aus, egal ob der Client die nun erreichen kann, oder nicht. Das hat sich seit Windows 2000 nicht geändert: Active Directory communication fails on multihomed domain controllers Ganz schlimm wird es, wenn Du mehr als ein Default Gateway einträgst. Das dürfte aber ab Windows 2008 nicht mehr gehen´. Zitieren Link zu diesem Kommentar
caballero 10 Geschrieben 12. November 2012 Autor Melden Teilen Geschrieben 12. November 2012 Ja.Wenn Du für die gleiche Adresse unterschiedliche IP-Adressen registrierst, macht der DNS-Server Round Robin und gibt für jede Abfrage eine andere Adresse aus, egal ob der Client die nun erreichen kann, oder nicht. Das hat sich seit Windows 2000 nicht geändert: Active Directory communication fails on multihomed domain controllers Ganz schlimm wird es, wenn Du mehr als ein Default Gateway einträgst. Das dürfte aber ab Windows 2008 nicht mehr gehen´. Zum Verständnis (ich bin noch in der Ausb.): Also ein Server (egal, welche Anwendung drauf) mit mehreren NICs = Adresse wird durch DNS mit mehreren IPs durch RR aufgelöst (das lässt sich bei mir ja grade nicht vermeiden, da auch EX CAS alle 5 NICs benutzen müssen um in allen Netzen erreichbar zu sein). Also würde der DNS bei jeder Anfrage auf einen Server alle IPs nach RR ausgeben, egal ob im selben Netz. Und der Client arbeitet die stumpf ab. Gilt das auch für das Exchange CAS Array? Wieso kann der DNS nicht einfach die IP ausgeben, die sich im gleich Netz befindet! Da ich ja ein 2 Srv DAG mit CAS array und 2 DC/DNS eingerichtet habe und sich die AD/DNS replizieren, werden wahrscheinlich alle 10 IPs (z.B. 5 von DC Primärhost, 5 Backuphost) aufgelöst. Ich hoffe nicht? Ne habe nur ein GW.... Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 13. November 2012 Melden Teilen Geschrieben 13. November 2012 Moin, um noch ein letztes Mal darauf zurückzukommen: Das ganze Konzept ist nicht stimmig. Du hebst deine mühsam aufgebaute Netztrennung auf, wenn alle Server in jedem Netz hängen (oder auch wenn nur ein Server in jedem Netz hängt, auf den die User draufkommen). Du hast immer noch nicht beantwortet, warum die Clients netzweise getrennt sein sollen, wenn sie gleichzeitig dieselben Ressourcen nutzen dürfen. Da das Problem üblicherweise die Ressourcen sind, erschließt sich mir der ganze Ansatz nicht. Um die Clients voneinander zu trennen, reicht die Windows-Firewall üblicherweise völlig aus. Abgesehen davon, nützt reine Netzwerk-Aufteilung auch nichts, wenn keine Firewall die Netze tatsächlich voneinander trennt. Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.