Jump to content

DerMichl

Members
  • Gesamte Inhalte

    18
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von DerMichl

  1. Wie hilft mir das? ;-)   1.1Algorithms for traffic distribution

    Outbound traffic can be distributed among the available links in many ways. One rule that guides any distribution algorithm is to try to keep all packets associated with a single flow (TCP-stream) on a single network adapter. This rule minimizes performance degradation caused by reassembling out-of-order TCP segments.

    NIC teaming in Windows Server 2012 supports the following traffic distribution algorithms:

    • Hyper-V switch port. Since VMs have independent MAC addresses, the VM’s MAC address or the port it’s connected to on the Hyper-V switch can be the basis for dividing traffic. There is an advantage in using this scheme in virtualization. Because the adjacent switch always sees a particular MAC address on one and only one connected port, the switch will distribute the ingress load (the traffic from the switch to the host) on multiple links based on the destination MAC (VM MAC) address. This is particularly useful when Virtual Machine Queues (VMQs) are used as a queue can be placed on the specific NIC where the traffic is expected to arrive. However, if the host has only a few VMs, this mode may not be granular enough to get a well-balanced distribution. This mode will also always limit a single VM (i.e., the traffic from a single switch port) to the bandwidth available on a single interface. Windows Server 2012 uses the Hyper-V Switch Port as the identifier rather than the source MAC address as, in some instances, a VM may be using more than one MAC address on a switch port.
    • Address Hashing. This algorithm creates a hash based on address components of the packet and then assigns packets that have that hash value to one of the available adapters. Usually this mechanism alone is sufficient to create a reasonable balance across the available adapters.

    The components that can be specified as inputs to the hashing function include the following:

    • Source and destination MAC addresses
    • Source and destination IP addresses
    • Source and destination TCP ports and source and destination IP addresses

    The TCP ports hash creates the most granular distribution of traffic streams resulting in smaller streams that can be independently moved between members. However, it cannot be used for traffic that is not TCP or UDP-based or where the TCP and UDP ports are hidden from the stack, such as IPsec-protected traffic. In these cases, the hash automatically falls back to the IP address hash or, if the traffic is not IP traffic, to the MAC address hash.

    1.2Interactions between Configurations and Load distribution algorithms 1.2.1Switch Independent configuration / Address Hash distribution

    This configuration will send packets using all active team members distributing the load through the use of the selected level of address hashing (defaults to using TCP ports and IP addresses to seed the hash function).

    Because a given IP address can only be associated with a single MAC address for routing purposes, this mode receives inbound traffic on only one team member (the primary member).  This means that the inbound traffic cannot

    • mode will also always limit a single VM (i.e., the traffic from a single switch port) to the bandwidth available on a single interface. Windows Server 2012 uses the Hyper-V Switch Port as the identifier rather than the source MAC address as, in some instances, a VM may be using more than one MAC address on a switch port.
    • Address Hashing. This algorithm creates a hash based on address components of the packet and then assigns packets that have that hash value to one of the available adapters. Usually this mechanism alone is sufficient to create a reasonable balance across the available adapters.

    The components that can be specified as inputs to the hashing function include the following:

    • Source and destination MAC addresses
    • Source and destination IP addresses
    • Source and destination TCP ports and source and destination IP addresses

    The TCP ports hash creates the most granular distribution of traffic streams resulting in smaller streams that can be independently moved between members. However, it cannot be used for traffic that is not TCP or UDP-based or where the TCP and UDP ports are hidden from the stack, such as IPsec-protected traffic. In these cases, the hash automatically falls back to the IP address hash or, if the traffic is not IP traffic, to the MAC address hash.

    1.1Interactions between Configurations and Load distribution algorithms 1.1.1Switch Independent configuration / Address Hash distribution

    This configuration will send packets using all active team members distributing the load through the use of the selected level of address hashing (defaults to using TCP ports and IP addresses to seed the hash function).

    Because a given IP address can only be associated with a single MAC address for routing purposes, this mode receives inbound traffic on only one team member (the primary member).  This means that the inbound traffic cannot exceed the bandwidth of one team member no matter how much is getting sent.

    This mode is best used for:

    1. Native mode teaming where switch diversity is a concern;
    2. Active/Standby mode teams; and
    3. Teaming in a VM.

     

    It is also good for:

    1. Servers running workloads that are heavy outbound, light inbound workloads (e.g., IIS).
    1.1.2Switch Independent configuration / Hyper-V Port distribution

    This configuration will send packets using all active team members distributing the load based on the Hyper-V switch port number.  Each Hyper-V port will be bandwidth limited to not more than one team member’s bandwidth because the port is affinitized to exactly one team member at any point in time.

    Because each VM (Hyper-V port) is associated with a single team member, this mode receives inbound traffic for the VM on the same team member the VM’s outbound traffic uses.  This also allows maximum use of Virtual Machine Queues (VMQs) for better performance over all. 

    This mode is best used for teaming under the Hyper-V switch when

    1. The number of VMs well-exceeds the number of team members; and
    2. A restriction of a VM to not greater than one NIC’s bandwidth is acceptable
  2. Weder noch, du beantwortest nicht alle Fragen ;)

    Doch ich versuches... ;-)

    Es kommt darauf mit welchem Alg das Balancing/Bonding arbeitet.

    Wie soll ich das raus bekommen?

    Wenn anhand SRC- und DST-Port gebalanced wird und du nur eine FTP Verbindung zum testen nimmst, kann das zwangsläufig nur über ein Kabel gehen. 

    Ist eine SMB Copy von SRV1 to SRV2

     

    So einfach ist das ... 

    Mehr oder weniger. ,-)

     

    Danke Micha

  3. Servus, hier der Dump, ich dachte LACP ist die Summer der Nics.. oder?

     

    Laut Handbuch sind die LACP Ports konfiguriert ;-)

     

    Und nein die Platten sind es definitiv nicht (8Port LSI  mit 6x 600GB 15KSas)

     

     

    Get-NetLbfoTeam


    Name                   : TEAM1
    Members                : {Ethernet 4, Ethernet 3, Ethernet 2, Ethernet 1}
    TeamNics               : TEAM1
    TeamingMode            : Lacp
    LoadBalancingAlgorithm : TransportPorts
    Status                 : Up


     Get-VMSwitch

    Name            SwitchType NetAdapterInterfaceDescription
    ----            ---------- ------------------------------
    SWITCH EXTERN   External   Microsoft Network Adapter Multiplexor Driver
    SWITCH INTERNAL Internal


     Get-VMNetworkAdapter -ManagementOS

    Name            IsManagementOs VMName SwitchName      MacAddress   Status IPAddresses
    ----            -------------- ------ ----------      ----------   ------ -----------
    SWITCH INTERNAL True                  SWITCH INTERNAL 00155D64D602 {Ok}
    SWITCH EXTERN   True                  SWITCH EXTERN   001E67652F3C {Ok}

  4. Microsoft empfiehlt sie in die Domäne zu nehmen. BP

     

    Zitat von Windows Pro:

    Administration, Backup und Restore

    Domain Controller dürfen weder per VHD-Kopie gesichert, von einer solchen wiederhergestellt, noch Snapshots von ihnen erstellt werden. Wesentliche Vorteile der Virtualisierung treffen deshalb auf DCs nicht zu – kein Hinderungsgrund, aber einer mehr abzuwägen, ob ein DC auf einer VM wirklich sinnvoller untergebracht ist als auf einem physischen Host. Virtuelle Domain Controller müssen deshalb so konfiguriert werden, dass die im Falle eines Host-Shutdowns ebenfalls heruntergefahren werden, und zwar ohne dass ihr Status gesichert wird.

     

    So bin ich hin und hergerissen. ;-)

     

    Du meinst es ist in dem kleinen Umfeld besser die Hosts nicht als DC zu haben?

    .

  5. Servus Dukel,

     

    Sorry für mich sinds Gedanklich immernoch PDC und BDC, aber du hast natürlich Recht...

     

    also der Plan war / Ist.  Host1 / Host2 je als DC zu setzen.

    Hyper V mit replizierung auf die andere Kiste zwecks Ausfallsicherheit.

     

    Blech 1                Blech 2

    a                  ->      A

    b                 ->       B

    D      <-                 d

    E      <-                 e

    usw.

     

    DIe 2 Hardware Kisten sind nun schon in der Domain und laufen.

  6. Servus, ich habe einen 2910 AL+ und möchte 2 meiner Server mit je einer 4x NIC via 2910 verbinden.

     

    Also Port 1357 mit  SRV 1 verbunden - NICTEAM Mit LACP eingerichtet, alles CAT6a gepatched (-> Ein VSwitch extern)

    Also Port 2579 mit  SRV 2 verbunden - NICTEAM Mit LACP eingerichtet, alles CAT6a gepatched (-> Ein VSwitch extern)

     

    Dannach im Switch alle 8 Ports auf LACP active eingestellt. 1GBIT FDX

     

    Das funktioniert leider nicht, beim kopieren von 1 -> 2 komme ich immer mit 113 MB/s an.

     

    Der Switch ist auf der Aktuellen FW W.15.08.0012, ROM W.14.06

     

    Was mache ich falsch? Evtl ein fehler im Vswitch? Wobei ich von Host zu Host kopiere.

     

    Switch Screen anbei.

     

    UPS, Hoffe ich bin hier richtig, wenn nicht, bitte um huldvolle verschiebung ;-)

    post-65977-0-46520500-1363038923_thumb.png

    post-65977-0-98769600-1363039147_thumb.png

    post-65977-0-83685400-1363039279_thumb.png

    post-65977-0-32479200-1363039286_thumb.png

    post-65977-0-61762400-1363039329_thumb.png

  7. Hallo zusammen,

     

    habe ein paar Fragen im Zusammenhang Planung/Umrüstung bestehendes Netzwerk auf Srv2012 mit HyperV.

     

    Aktuell haben wir 4 Physische Server mit 4 x Server2003 – 32Bit. Grob:

    Fileserver – PDC  

    Mailsrv – BDC Kein Exchange

    Transfer – BDC

    Terminal – Member (~ 25 User) + Drucker spool

    Das will ich Migrieren.

     

    Neue Hardware: 2 x Kampfmaschinen mit 64GB Ram,2x200SSD, 6x600GB SAS RAID5, 2 x XEON DP E5, RMM4, Neueste Technologie R2308GZ4GC, QNAP 8x3 High Performance NAS mit 2 x Acronis Virtual Edition zur Datensicherung. Soll jeweils auf dem Host installiert werden. Keine Core Installation der Hosts. (Da ich keine Erfahrung mit der Performance habe, musste ich ein wenig Grösser hinfahren als wohl nötig wäre)

    Installation SRV2012 auf beiden Maschinen, Domänenbeitritt, einer PDC einer DC,

    Darauf laufen temporär 2x2 Maschinen SRV2003 und 2x2 Maschinen SRV2012 bis die Maschinen von 2003 in 2012 migriert sind.

    Danach sollen sich die Jeweils 2 Maschinen auf den anderen Host replizieren. (Habe also auf jedem Host 2aktive und 2 passive Maschinen.

    Ein weiterer Server ist nicht geplant. Die Domain läuft im 2003 Modus.

     

    Fallen da bisher Denkfehler auf? Verbesserungen? Ablaufplan?

     

    Vielen Dank

    michl

×
×
  • Neu erstellen...