Archive Page 2

Skype im Netz von T-Mobile: Abgehackte Gespräche ohne die Option „Internet Telefonie“

Vor einigen Tagen rief mich ein Benutzer an und berichtete, dass Skype-Gespräche über seine T-Mobile UMTS Karte im Notebook nicht möglich wären: Wenige Sekunden nach dem Verbindungsaufbau wäre der Gesprächspartner angeblich kaum zu verstehen und alles klinge „abgehackt“.

Ein kurzer Test bestätigte die Schilderung: Trotz guter UMTS Verbindung war über Skype kein normales Gespräch möglich, selbst der Skype Echo Test klang nach wenigen Sekunden so abgehackt, dass er schlicht nicht zu gebrauchen war. Darüberhinaus waren Downloads von skype.com nur mit extrem niedrigen Geschwindigkeiten möglich:

skype-umts

Eingesetzt wurde eine SIM Karte von T-Mobile mit dem Tarif „CombiCard Business Mobile Data M“, mit dem monatlich 3GB schnelles Datenvolumen genutzt werden können. Normalweise würde man erst mal davon ausgehen, dass die Nutzung von Skype hier mit eingeschlossen ist.

Im Kleingedruckten versteckt sich allerdings eine wichtige Information hinsichtlich der Nutzung von Voice over IP:

    Die Flatrate kann nicht für BlackBerry, VoIP (Voice over IP), Instant Messaging und Peer-to-Peer Verkehre genutzt werden.

Laut Webseite kann die Nutzung von VoIP mittels der Option „Internet Telefonie“ für mtl. 9,99 EUR hinzugebucht werden. Eine erste Rückfrage bei der Telekom ergab allerdings, dass die Nutzung von Skype trotzdem möglich sein müsse und der Fehler am Endgerät liegen muss. Geblockt würde bei T-Mobile definitiv nichts.

Nach weiteren Tests stellte sich allerdings heraus, dass Skype in folgenden Fällen ebenfalls nicht funktionierte:

    – auf anderen Notebooks mit anderer UMTS Hardware
    – auf einem iPhone mit der Skype App
    – mit anderen Datenkarten von T-Mobile
    – an verschiedenen Standorten (Netzabdeckung)

Mit einer Karte von Vodafone funktionierte es dagegen sofort. Auch mit der Karte eines Kollegen und dem Tarif „Complete Mobil L“, in dem die VoIP Option bereits enthalten ist, gab es keine Probleme und Skype funktionierte einwandfrei.

Eine zweite Nachfrage bei der Telekom, ob denn wirklich nichts geblockt würde und man dies nicht noch mal überprüfen könne, ergab dann folgende Antwort:

    Aktuell ist für Sie der Tarif CombiCard Business Mobile Data M (Mobilfunk) hinterlegt. Mit diesem Tarif verfügen Sie über eine Internet-Flatrate.

    Die zubuchbare Internet Telefonie Option, auch VoIP-Option, ermöglicht es, Skype zu nutzen. Wir berechnen für diese Option einen monatlichen Grundpreis von 8,36 Euro netto bei einer Mindestvertragslaufzeit von drei Monaten.

    Jeder Tarif, bei dem es möglich ist, die Internet Telefonie Option dazu zu wählen, kann auch für Skype genutzt werden. Gern stehen Ihnen die Mitarbeiter in unserem Servicecenter auch telefonisch für Fragen zu unseren Tarifen zur Seite.

Wie aus der Antwort hervorgeht, wird die Option „Internet Telefonie“ für die Nutzung von Skype definitiv benötigt. Wenige Minuten nach dem Buchen der Option funktionierte Skype dann tatsächlich einwandfrei.

De facto werden Verbindungen zu Skype.com also in ihrer Geschwindigkeit gedrosselt, wenn die entsprechende Option nicht gebucht ist.

Advertisements

Exchange 2010: Probleme bei der Einrichtung einer DAG

Die Einrichtung einer Database Availability Group in Exchange 2010 ist gut dokumentiert. Das entsprechende Hintergrundwissen und eine sorgfältige Planung vorausgesetzt, lässt sich die Implementation einer DAG relativ schnell über die Bühne bringen.

Was nicht so gut dokumentiert ist: Zur Vorbereitung gehört auch die Installation diverser Hotfixe, die Microsoft für den Betrieb eines Failover Clusters empfiehlt und die deshalb für Server einer DAG ebenfalls empfehlenswert sind. Informationen zu den Hotfixes gibt es hier und hier.

Dass eine gute Vorbereitung aber keine Garantie für eine völlig problemlose Umsetzung ist, zeigt die Einrichtung einer DAG mit zwei Servern vom letzten Wochenende:

Seeding neuer Datenbankkopien schlägt fehl

Beim Seeden neuer Datenbankkopien über die EMC kam es wiederholt zu folgendem Fehler:

Error:
A source-side operation failed. Error An error occurred while performing
the seed operation. Error: Failed to open a log truncation context to
source server 'ex01.layer9.local'. Hresult: 0xfffffae7. Error: The database
was either not found or was not replicated.. [Database: MBDB001, Server:
ex02.layer9.local]

Failed to open a log truncation context to source server 'ex01.layer9.local'.
Hresult: 0xfffffae7. Error: The database was either not found or was not
replicated. Click here for help...

Danach befand sich die neu angelegte Kopie im Zustand „Suspended“ oder „Failed and Suspended“. Geholfen hat ein anschließendes, manuelles Update der Kopie mittels PowerShell:

[PS] C:\>Update-MailboxDatabaseCopy -Identity MBDB001\EX02

Unter Umständen kann es eine Weile dauern, bis das manuelle Update funktioniert. Sollte das alleine nicht helfen, kann zusätzlich die aktive Datenbank heruntergefahren und alle Transaktionslogs gelöscht werden. Spätestens dann sollte das Seeding klappen.

ContentIndex State der Kopie steht auf „Crawling“, hohe CPU Last durch msftefd.exe

Bei einigen Kopien verblieb der ContentIndex State auf „Crawling“ und die CPUs des Servers, der die Kopien hostet, wurde durch den Prozess msftefd.exe vollständig ausgelastet.

In diesem Fall muss auf dem betreffenden Server der Dienst „Microsoft Exchange Search Indexer“ neu gestartet und anschließend der Content Index der betreffenden Datenbankopien manuell aktualisiert werden:

[PS] C:\Update-MailboxDatabaseCopy –Identity MBDB001\EX02 –CatalogOnly

Wenn sich der Dienst nicht mehr beenden lässt, kann der Prozess msftefd.de im Task Manager einfach beendet werden. Nach dem Aktualisieren des Content Index sollte der Status von „Crawling“ auf „Healthy“ wechseln und die hohe CPU-Last verschwinden.

Unerwarteter Failover des Owner Nodes im Cluster und IP Adressen Konflikt

Die DAG bzw. der Cluster besteht aus den zwei Exchange Servern EX01/EX02 und einem Fileserver mit dem Witness-Share. Am Abend nach der Einrichtung kam es zu einem zunächst nicht nachvollziehbaren Failover des OwnerNodes der Clustergruppe von Server EX02 zu EX01. Darüberhinaus wurde auf der Konsole von EX01 ein IP-Konflikt angezeigt:

ip-conflict

Auf EX01 wurden in diesem Zusammenhang nacheinander folgende Cluster Events protokolliert:

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:10:50
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster node 'EX02' was removed from the active failover cluster membership. 
The Cluster service on this node may have stopped. This could also be due to
the node having lost communication with other active nodes in the failover
cluster. Run the Validate a Configuration wizard to check your network
configuration. If the condition persists, check for hardware or software
errors related to the network adapters on this node. Also check for failures
in any other network components to which the node is connected such as hubs,
switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:04
Event ID:      1049
Task Category: IP Address Resource
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster IP address resource 'Cluster IP Address' cannot be brought online
because a duplicate IP address '172.16.1.2 was detected on the network. Please
ensure all IP addresses are unique.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:04
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster resource 'Cluster IP Address' in clustered service or application 'Cluster
Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:12
Event ID:      1049
Task Category: IP Address Resource
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster IP address resource 'Cluster IP Address' cannot be brought online
because a duplicate IP address '172.16.1.2' was detected on the network. Please
ensure all IP addresses are unique.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:12
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster resource 'Cluster IP Address' in clustered service or application 'Cluster
Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:13
Event ID:      1205
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
The Cluster service failed to bring clustered service or application 'Cluster
Group' completely online or offline. One or more resources may be in a failed
state. This may impact the availability of the clustered service or application.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:19:28
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster node 'EX02' was removed from the active failover cluster membership. The
Cluster service on this node may have stopped. This could also be due to the node
having lost communication with other active nodes in the failover cluster. Run the
Validate a Configuration wizard to check your network configuration. If the condition
persists, check for hardware or software errors related to the network adapters on
this node. Also check for failures in any other network components to which the node
is connected such as hubs, switches, or bridges.

Und auf Server EX02 wurden diese Ereignisse protokolliert:

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:10:50
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster node 'ex01' was removed from the active failover cluster membership. The Cluster
service on this node may have stopped. This could also be due to the node having lost
communication with other active nodes in the failover cluster. Run the Validate a
Configuration wizard to check your network configuration. If the condition persists,
check for hardware or software errors related to the network adapters on this node. Also
check for failures in any other network components to which the node is connected such
as hubs, switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1564
Task Category: File Share Witness Resource
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
File share witness resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)'
failed to arbitrate for the file share '\\\\witness.layer9.local\DAG001.layer9.local'. Please
ensure that file share '\\witness.layer9.local\DAG001.layer9.local' exists and is accessible
by the cluster.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)' in clustered
service or application 'Cluster Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due to
the loss of network connectivity between some or all nodes in the cluster, or a
failover of the witness disk. Run the Validate a Configuration wizard to check your
network configuration. If the condition persists, check for hardware or software errors
related to the network adapter. Also check for failures in any other network components
to which the node is connected such as hubs, switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:19:28
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster node 'ex01' was removed from the active failover cluster membership. The Cluster
service on this node may have stopped. This could also be due to the node having lost
communication with other active nodes in the failover cluster. Run the Validate a Configuration
wizard to check your network configuration. If the condition persists, check for hardware
or software errors related to the network adapters on this node. Also check for failures
in any other network components to which the node is connected such as hubs, switches, or
bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:29
Event ID:      1564
Task Category: File Share Witness Resource
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
File share witness resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)'
failed to arbitrate for the file share '\\witness.layer9.local\DAG001.layer9.local'. Please
ensure that file share '\\witness.layer9.local\DAG001.layer9.local' exists and is accessible
by the cluster.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:29
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)' in
clustered service or application 'Cluster Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:59
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due
to the loss of network connectivity between some or all nodes in the cluster, or
a failover of the witness disk. Run the Validate a Configuration wizard to check
your network configuration. If the condition persists, check for hardware or
software errors related to the network adapter. Also check for failures in any
other network components to which the node is connected such as hubs, switches,
or bridges.

Anschließend wurde der Cluster Service auf EX02 neu gestartet und der Cluster funktionierte wieder. Aber wie kam es zu dem unerwarteten Failover und dem Konflikt der DAG-IP-Adresse?

Beide Server sind virtuelle Maschinen und waren dauerhaft online. Und eine doppelt vergebene IP-Adresse konnte definitiv ausgeschlossen werden. Also noch mal einen Blick in die Logfiles werfen und überlegen, was zu dieser Uhrzeit alles so im Netzwerk passiert sein konnte.

Und da kam eigentlich nur eins in Frage: Das Backup der virtuellen Maschinen mit Veeam Backup & Replication.

Beim Blick in die Logfiles von Veeam stellte sich dann tatsächlich heraus, dass kurz vor dem ersten Clusterfehler um 21:10:50 das Backup von EX02 startete. Nämlich genau 24 Sekunden vorher um 21:10:26:

veeam-ex02

Dabei auffällig ist die mit 16 Sekunden relativ lange Zeit, die für den Snapshot der virtuellen Maschine anfiel.

Und genau hier liegt die Ursache für das ganze Problem: Offenbar kam es aufgrund einer durch das Backup und den Snapshot bedingten sehr hohen I/O-Last zu einem kurzen Timeout von EX02 und damit zu einem Failover des Cluster Owner Nodes von EX02 zu EX01.

Die IP-Adresse der DAG bzw. des Clusters gehört immer dem Owner Node, war also bis zum Failover an die NIC von EX02 gebunden. Im Rahmen des Failovers wanderte die IP-Adresse demnach ordnungsgemäß zu EX01.

Aber jetzt kommt es: Da EX02 aufgrund des Snapshots für kurze Zeit de facto „eingefroren“ und wenige Sekunden später wieder online war, existierte die IP-Adresse dort ebenfalls noch. Ergebnis: IP-Adress-Konflikt und die daraus resultierenden Probleme im Cluster.

In diesem Zusammenhang ist von Bedeutung, nach welcher Zeitspanne ein Failover im Cluster stattfindet. Standardmäßig sind es fünf Sekunden [1]:

    By default, regardless of subnet configuration, heartbeat frequency (also known as subnet delay) is once every second (1000 milliseconds). The range for heartbeat frequency is once every 250-2000 milliseconds on a common subnet, and 250-4000 milliseconds across subnets. By default, when a node misses a series of 5 heartbeats, another node will initiate failover, and the range for this value (also known as subnet threshold) is from 3 through 10.

Befinden sich alle Nodes des Clusters im selben Subnet, lässt sich der Timeout mit den Werten „SameSubnetDelay“ und „SameSubnetThreshold“ festlegen. Die im Cluster DAG0001 verwendeten Werte lassen sich in der Eingabeaufforderung wie folgt ermitteln:

cluster /cluster:DAG001 /prop

T  Cluster              Name                           Value
-- -------------------- ------------------------------ -----------------------
DR DAG001               FixQuorum                      0 (0x0)
DR DAG001               PreventQuorum                  0 (0x0)
DR DAG001               IgnorePersistentStateOnStartup 0 (0x0)
SR DAG001               SharedVolumesRoot              C:\ClusterStorage
D  DAG001               AddEvictDelay                  60 (0x3c)
D  DAG001               BackupInProgress               0 (0x0)
D  DAG001               ClusSvcHangTimeout             60 (0x3c)
D  DAG001               ClusSvcRegroupOpeningTimeout   5 (0x5)
D  DAG001               ClusSvcRegroupPruningTimeout   5 (0x5)
D  DAG001               ClusSvcRegroupStageTimeout     7 (0x7)
D  DAG001               ClusSvcRegroupTickInMilliseconds 300 (0x12c)
D  DAG001               ClusterGroupWaitDelay          30 (0x1e)
D  DAG001               ClusterLogLevel                3 (0x3)
D  DAG001               ClusterLogSize                 100 (0x64)
D  DAG001               CrossSubnetDelay               1000 (0xfa0)
D  DAG001               CrossSubnetThreshold           5 (0xa)
D  DAG001               DefaultNetworkRole             2 (0x2)
S  DAG001               Description
D  DAG001               EnableSharedVolumes            0 (0x0)
D  DAG001               HangRecoveryAction             3 (0x3)
D  DAG001               LogResourceControls            0 (0x0)
D  DAG001               PlumbAllCrossSubnetRoutes      0 (0x0)
D  DAG001               QuorumArbitrationTimeMax       90 (0x5a)
D  DAG001               RequestReplyTimeout            60 (0x3c)
D  DAG001               RootMemoryReserved             4294967295 (0xffffffff)
D  DAG001               SameSubnetDelay                1000 (0x7d0)
D  DAG001               SameSubnetThreshold            5 (0xa)
B  DAG001               Security Descriptor            01 00 04 80 ... (164 bytes)
D  DAG001               SecurityLevel                  1 (0x1)
M  DAG001               SharedVolumeCompatibleFilters
M  DAG001               SharedVolumeIncompatibleFilters
D  DAG001               ShutdownTimeoutInMinutes       20 (0x14)
D  DAG001               WitnessDatabaseWriteTimeout    300 (0x12c)
D  DAG001               WitnessRestartInterval         15 (0xf)

Um die Zeitspanne für ein Failover im selben Subnetz auf den Maximalwert von 20 Sekunden zu vergrößern, werden einfach folgende Befehle ausgeführt:

cluster /cluster:DAG001 /prop SameSubnetDelay=2000
cluster /cluster:DAG001 /prop SameSubnetThreshold=10

Anschließend wird ein Failover nicht bereits nach fünf, sondern erst nach 20 Sekunden durchgeführt. Hier sollte dann genügend Luft für entsprechende Timeouts vorhanden sein.

[1] Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster

Fehler „Log Truncation failed“ bei Datenbankkopien

Nach dem Einrichten der Datenbankkopien fiel auf, dass auf dem Server, der die Kopien hostet, für jede Datenbankkopie permanent folgender Fehler im Eventlog protokolliert wurde:

Log Name:      Application
Source:        MSExchangeRepl
Date:          18.02.2013 16:40:11
Event ID:      2137
Task Category: Service
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      ex02.layer9.local
Description:
RPC request to the Microsoft Exchange Information Store service for log truncation
failed for database MBDB005\EX02. Error: 4294965485.

Der Fehler verschwindet nach dem nächsten vollen Backup der aktiven Datenbankkopien und deren Transaktionsprotokollen.

Ansonsten noch ein genereller Tipp: Sollte in der GUI (EMC) irgendwas nicht sofort klappen, erst mal in der EMS mit dem zugrundeliegenden Cmdlet ausprobieren.