Kann eine Netzwerkarte automatisch die Aufgaben einer zweiten übernehmen?

Ein Trunk nützt dir gar nichts, denn der schafft immer nur Redundanz durch multiple Ports zu einem einzigen Switch und kann nicht auf 2 Switches gesplittet werden ! Trunking (oder Etherchannel wie Cisco es nennt..) dient auch primär der Durchsatzerhöhung bei der Anbindung von Servern und nicht der Redundanz...
Im Serverbereich gibt es eine Menge an Redundanzmeachnismen um so etwas abzufangen spezielle Switches benötigt man dafür nicht unbedingt. Ein klassiche Hochverfügbarkeitslösung ist aber nur in Verbindung mit den Switches zu realisieren.
Fangen wir da einmal an: Die Switches müssen in einem "Hot Standby" Verfahren mit VRRP oder VRRP-E laufen sofern deine Server mehrere Segmente (VLANs) bedienen müssen. Dies dient dazu um dein Gateway Problem zu lösen, sollte einer der Core Switches ausfallen.
Hast du allerdings ein "flaches" Layer 2 Netzwerk ohne VLANs benötigst du diesen Mechanismus nicht. Du musst dann lediglich dafür soregn, das deine Core switches immer redundant an die Access Switches angebunden sind ! Das setzt natürlich zwingend den Einsatz ein Spanning Tree Protokoll voraus sei es STP oder das modernere RSTP.
Im Server selber ist das einfachste man schaltet eine Karte in den Standby Mode. Mit guten Karten ala Intel, Broadcom etc. ist das einfach über die Treiberkonfig oder ein Zusatzprogramm machbar. Der Server aktiviert dann augenblicklich die redundante Karte sollte bei der primären der physische Link ausfallen.
Der Betrieb mit 2 aktiven Karten kann etwas "tricky" sein allerdings ist das abhängig vom Betriebssystem. Ein Unix Server den du z.B. nur per FTP oder HTTP betreibst hat dann 2 unterschiedliche IP Adressen und kann auch über die angesprochen werden. Mit einem DNS Load Balancing bekommst du problemlos eine transparente Redundanz für die Benutzer hin.
Bei Windows ist das nicht mehr ganz so einfach, da dessen Resourcen dynamisch nun synchron von beiden IP Adressen im Netz gebroadcastet werden, was meist Probleme verursacht auf der Clientseite. Eine Linksteuerung wie o.a. beschrieben ist wesentlich problemloser zu handeln. Wichtig ist nur darauf zu achten das die MAC Adressen unterschiedlich sind (ist aber wahrscheinlich bei 2 separaten Karten..) sonst hast du im Netzwerk wieder Probleme mit doppelten MACs und das geht gar nicht sofern es ein Layer 2 Szenario ohne VLANs ist !
Will man beide Adapter mit unterschiedlichen Netzadressen betreiben kann man diese Adapter in unterschiedliche IP Segmente bringt und dann wieder mit VLANs arbeitet, was dann aber ein VRRP Szenario wie oben bei den Switches voraussetzt entsprechende VLAN Fähigkeit der Switches sowieso...
So oder so kannst du dann aber einen Core Switch komplett ausschalten (oder ausfallen lassen..) ohne das es zu einem Verbindungsverlust mit dem Server kommt. Ein gängiges Verfahren für hochverfügbare Server....

Hallo Big Biff !

Nein, deine Annahme ist falsch das sich die Switches aktiv austauschen. Das können sie nicht denn es gibt kein Protokoll das dies regelt. Du schreibst du hast lediglich ein Layer 2 Szenario dann basiert bei dir alles auf MAC Adressen die ein Switch passiv in seiner CAM Table verwaltet.
Da liegt aber auch dein Problem, denn du benutzt eine problematische Konfiguration mit einer IP Adresse die 2 MACs besitzt:
Ein Endgerät schickt vor jedem Verbindungsaufbau ein ARP Request Packet (Adress Resolution Protokoll) als Broadcast ins gesamte Netz das die Switches auf alle Ports replizieren müssen (..ist ja ein Broadcast) denn der Client möchte gerne die MAC zur IP Adresse wissen. Nun nimmt das Unglück seinen Lauf..... Da du 2 unterschiedliche MACs auf einer IP Adresse sitzen hast (so schreibst du es für die Server Konfig) gehts nach dem Motto "first come first serve" also je nachdem welcher ARP Reply schneller ist landet im ARP Cache deines Clients. Danach geschieht dann der Verbindungsaufbau.
Fällt nun der Switch aus auf dessen Port die MAC Adresse liegt mit der der Client kommuniziert merkt der das erstmal nicht, denn der denkt das sein ARP Cache ok ist und versucht verzweifelt diese MAC zu erreichen. Irgendwann macht er vielleicht einen neuen ARP Request oder auch nicht, das ist von seinem TCP/IP Stack abhängig wie der auf sowas reagiert. Bei vielen Clients timen diese Verbindungen aus oder der User rebootet den Client frustiert, was dann natürlich den ARP Cache löscht und letztlich das Problem fixt.
Mit deiner Konfig kommst du aus der Zwickmühle nicht raus.
Du solltest die Adapter in ein sogen. Active - Standby Szenario nehmen. D.h. ein Link ist aktiv und der andere nur Standby. Beide sharen eine IP und MAC. Fällt der Aktive aus übernimmt sofort der Standby Link mit den gleichen Daten. Damit hast du dann ein sub second Failover sofern dein Servertreiber das fix handeln kann
Nachteil: Damit verlierst du die Load Sharing Möglichkeit, denn es ist ja nur ein Link aktiv.
Willst du beide Links aktiv haben musst du beiden auch jeweils eine unterschiedliche IP Host Adresse geben und unterschiedliche MACs. Über ein DNS Round Robin musst du nun dafür sorgen, das die Clients auf diese Adapter verteilt werden, bzw. im Failoverfalle auf den jeweils aktiven Port per DNS geschaltet werden. Das erfordert aber meist einen Loadbalancer oder eine extra SW Lösung im DNS.
Der Aufwand von ersterer Variante ist ungleich geringer und störungsärmer... Wenn du die Server mit GiG Karten anbindest sollte der LB Nachteil verschmerzbar sein.

Ja klar der Sprung auf eine L3 Infrastruktur würde das natürlich bedeuten. War hier auch nur primär als Beschreibung deiner beiden Möglichkeiten gedacht...
Dein Problem ist das die Edge Switches scheinbar nicht redundant an die Core Switches angebunden sind wenn ich die o.a. Liste richtig interpretiere.
In einem klassischen redundanten Netzwerk ist genau das aber immer der Fall und ausserdem haben die Core Switches natürlich noch einen Link zwischen sich selbst. STP oder RSTP sorgt dann wieder für redundante eindeutige Wege.
Was bleibt ist aber dein ARP Cache Problem bei den Clients bzw. Server bei zwei unterschiedlichen MACs pro Link. Fällt nun der Link eines Servers weg auf dem der Client aktiv arbeitet hat er ja immer noch dessen MAC im ARP Cache bzw. auch der Server. Beide Endgeräte müssen zwangsläufig im V-Fall neu arpen wenn ihre aktive MAC wegbricht.
Das wird in so einer Konstellation immer der Fall sein. Du bist dann immer auf Gedeih und Verderb auf die Funktionalität bzw. das verhalten deines TCP Stacks in Bezug auf ARPs angewiesen, wie der sich in so einem Falle verhält. Die Switchinfrastruktur hat da eher an zweiter Stelle mit zu tun sofern sie dann auch redundant ausgelegt ist.
Das ist erst anders wenn du mit active-standby arbeitest, da die MAC dann immer eindeutig ist. Das ist bei dir ja aber nicht gewollt.

Der Switch selbst "bevorzugt" nichts. Das Protokoll was dafür sorgt ist ein Spanning Tree Protokoll. Also entweder Standard Spanning Tree 802.1d oder rapid Spanning Tree 802.1w. Heutzutage nimmt man meist RSTP 802.1w wegen der schnelleren Konvergenzzeiten von Teils unter einer Sek. BPDU Packete sorgen dann dafür das in einem redundanten Netz mehrere Ports in den Blocking Mode gehen um so Loops zu verhindern. Normalerweise konfiguriert man STP über Priorities so das man fest vorgibt wer Root Bridge ist und wer nicht. Man muss es aber nicht, dann tritt allerdings der Fall ein das auch Edge Switches zu Root Bridges werden können und das kann im Link Fehler Fall fatal sein denn dann tritt ein STP Recalculation Vorgang ein. Bei Standard STP ist es umso schlimmer, da der aktiv dann eine neue Topologie errechnet und auch aktive Links vorübergehend in den Blocking State gehen. Dieser Zusatnd kann bis zu mehreren Minuten dauern.
Ich nehme mal an das das bei dir der Fall ist denn wenn man ein STP Netzwerk sauber customized dann passiert so etwas nicht. Das Ziehen deines Links zwischen den Core Switches ist auch ein sicheres Anzeichen dafür, denn das sollte eigentlich keinen Einfluss haben.
Heute nimmt man deshalb auch RSTP den RSTP macht diese Kalkulation der Redundanz schon vorher und bestimmt feste Redundanzlinks. Kann also folglich schneller umschalten und wieder zurück (Sofern man Draft 4 vom RSTP implementiert hat...)
Du solltest in deiner Netzwerk Konstellation unbedingt dafür sorgen das deine Core Switches (bzw. einer davon) immer Root Bridge ist und im V-Falle dann der andere.
Das ist einfach zu bewerkstelligen indem du dir die STP Topologie einmal ansiehst. Je nach Switch geht das mit dem "show stp" Kommando oder über einen Menüpunkt.
Was du machst ist die Bridge Priority der Core Switches über die Konfig hochzusetzen, das die im STP Prozess immer Root Bridges sind. Alternativ geht das auch über die Priority der Links und zwar einsetig auf der Core switch Seite. Das ist aber letztlich etwas mehr Konfig Aufwand.
In so einem Szenario sollte eigentlich alles so klappen wie wenn du deinen Core Switch Link ziehst