Bevezetés

Úgy alakult, hogy az egyik ügyfelemnél magas rendelkezésre állású Lync 2013-as környezetet kell(ett) építenem. Lync 2013 esetében ez gyakorlatilag egyet jelent az SQL mirroring használatával, mivel hivatalosan már nem támogatott az SQL clustering a Lync 2013 esetében. Ez a support állítás is megér majd később egy blog bejegyzést, de ezen most emelkedjünk felül.

Az SQL replica kiépítése nem túl komplikált a Lync esetében, ezért nem is tartottam tőle túlságosan. Az elképzelés az volt, hogy három kiszolgálónk lesz, egy primary, egy mirror és egy witness kiszolgálóval:

Ahogy említettem a mirroring kialakítása egyszerű. A támogatott SQL verziók valamelyikét kell telepíteni, majd a Topology Builder alkalmazásban beállítáni, hogy ki a mirror és ki a witness:

Ezt követi szerencsés esetben a topológia publikálása. Ami az ügyfélkörnyezetében valamint a saját demo környezetemben is konzekvens módon a következő hiba jelent jött:

Megpróbáltam Powershell segítségével a –verbose paraméterrel is, hátha több és hasznosabb információt kapok (sajnos nem hozta a várt eredményt):

Problémafeltárása

Sajnos magamra maradtam, a belső tudásbázisunkban semmi használható információt nem találtam. Így maradt a magányos problémafeltárás ami jó kaland, pláne akkor ha elég sok információnk van ahhoz, hogy a hibát megoldjuk. Két fontos információ áll rendelkezésünkre:

• DsRoleGetPrimaryDomainInformation– ezt a függvényt hívjuk és ez a hívás ad vissza hibát. A stackben tisztán látszik, hogy ez az utolsó hívás.
• 6BA– ezt a hibát adja vissza a DsRoleGetPrimaryDomainInformation függvény

Általában a hibából indulok ki, utána próbálom azt összeegyeztetni az adott funkció működésével. Az ERR.EXE kiváló, egyben pótolhatatlan eszköz arra, hogy a hibakódokat “visszafejtsük”. Most is az err.exe –t hívtam segítségül, amivel sikerült megállapítani azt, hogy a 6BA = “The RPC server is unavailable”. Eddig ez 5 perc.

Ha az RPC server nem elérhető, akkor joggal élhetünk, azzal a feltételezéssel, hogy valami kommunikációs hiba van és első, előkelő helyen szerepel a gyanúsított listán a szerveren levő tűzfal. De mielőtt előre rohanunk, gondolkodjunk kicsit. A függvény hívásakor kapjuk az RPC server nem elérhető hibaüzenetet. De vajon milyen porton akar kommunikálni? Ha ez valós RPC forgalom, akkor a How RPC Works leírás lehet segítségünkre. Hosszú olvasmány, de ebből ami nekünk fontos az az, hogy a TCP 135, TCP 445 és dinamikus port range jöhet szóba. Egy másik lehetséges irány a port megtalálásához az, ha DsRoleGetPrimaryDomainInformation függvényt megnézzük az MSDN-en.

Itt megtalálhatjuk azt, hogy ez a függvény a netapi32.dll-ben van implementálva:

Történelmileg a netapi32.dll-ben több sérülékenység is volt, ami TCP 135 és / vagy TCP 445 portokon keresztül folt támadható. Ennek kiderítése szintén kb. 5 percnyi munka.

Megvan a hiba, van egy sejtésünk, hogy a TCP 135 vagy a TCP 445 porton keresztül nem érhető el a Master SQL szerver. Nincs is más dolgunk, mint elindítani újra az adatbázis telepítést és közben hálózati monitorozást végezni. Rászűrve a TCP 445-re egy érdekes dolog látható:

A Front-end kiszolgáló háromszor próbálja elküldeni ugyanazt a csomagot, de nincs válasz. Bingo. Újabb 5 perc.

Probléma

Ha a Front-End kiszolgáló nem éri el az SQL szervereket a TCP 445-s porton keresztül, akkor a database mirror kialakítása a következő hibával megáll: DsRoleGetPrimaryDomainInformation failed with error “6BA”

Megoldás

A lokális tűzfal helyes konfigurálásának több módja is van. Az egyik lehetséges megoldás egy új tűzfalszabály létrehozása ami engedélyezi a TCP 445-s portot:

A tűzfalszabály létrehozása után az SQL mirror kialakítása hiba nélkül lefut:

Zárszó

Néhány záró gondolat a végére:

• A hiba az íróasztalomon hevert január óta. Tudtam, hogy megoldom, csak eddig időm nem volt rá. A határidő viszont a legnagyobb múzsa. Kedden jön hozzám az ügyfelem. Figyelj Gergő, a hibát megoldottam.
• Megoldás a lokális tűzfal kikapcsolása. Több ügyfelem is most mondhatja, hogy bezzeg, ha nem lenne tűzfal, akkor nem lenne ez a probléma, tehát igazunk van, kapcsoljuk ki. Továbbra is azt mondom, hogy NE.
• A tűzfal helyes konfigurálása többféle módon is megtörténhet. A TCP 445 portot több protokoll is használja, ezért egy File and Printer Sharing látszólag kinyitja és engedélyezi a forgalmat, de nem lesz teljes értékű.
• Nem, minden az aminek látszik. Első ránézésre ez egy komoly SQL Mirror hibának tűnik. Először pánikoltam, mert nem értek az SQL-hez mélyen. De nem minden az aminek látszik és itt is bebizonyosodott, hogy alapos platform ismeret kiment a bajból.
• Laci, tiéd a következő ilyen hiba megoldása.