VNX: DOMAIN_CONTROLLER_NOT_FOUND SMB2-suojattua kanavaliikennettä tukevan koodin päivittämisen jälkeen

Koodi on päivitetty johonkin edellä luetelluista versioista.

Kun johonkin seuraavista koodeista oli päivitetty, lokeihin alkoi tulla virheilmoituksia, joiden mukaan toimialueen ohjauskone ei toiminut:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Viesti näyttää tältä:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

Kaikki edellä mainitut koodit lisätään uuteen ominaisuuteen, jonka avulla NAS-palvelin tai tietojen siirtäjä voi kommunikoida SMB2:n toimialueen ohjauskoneiden kanssa. Ennen tätä koodia toimialueen ohjauskoneen tietoliikenne hoidettiin SMB1:ssä (vaikka asiakkaat saattoivat edelleen keskustella kanssamme SMB2/SMB3:ssa).
SMB2:een siirtymisen myötä kaikkia komentoja ei sarjoiteta toimialueen ohjauskoneisiin. Tämä näyttää johtavan siihen, että jotkin komennot suoritetaan samanaikaisesti rinnakkain.
Esimerkki on yritys avata nimetty lsarpc-niminen putki.

Tässä virhesanomassa on tärkeää huomata palvelu, johon yritämme sitoa:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

Virheilmoituksesta nähdään, että se yrittää avata LSA:n (korostettu punaisella). Tässä kohtaa ongelma astuu kuvaan. Yritämme avata lsarpc-nimisen putken useita kertoja samanaikaisesti, ennen kuin saamme vastauksen DC: ltä. Ensimmäinen pyyntö onnistuu, mutta seuraavat epäonnistuvat. Virheilmoitukset ilmaisevat STATUS_PIPE_NOT_AVAILABLE, ja kirjaamme DOMAIN_CONTROLLER_NOT_FOUND-ilmoituksen lokeihin.

On tärkeää huomata, että nämä viestit eivät aina osoita tätä ongelmaa. DOMAIN_CONTROLLER_NOT_FOUND virheillä voi olla monia syitä.
Tämän nimenomaisen lokeissa on todennäköisesti paljon seuraavia tietoviestejä:

2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened

Jos on kysyttävää siitä, vastaako ongelma ongelmaa vai ei, se voidaan vahvistaa paketin jäljityksessä. Jäljityksessä näemme useita samanaikaisia pyyntöjä avata lsarpc ennen vastauksen saamista mihinkään niistä, jota seuraa ensimmäinen peräkkäinen ja seuraavat epäonnistuvat STATUS_PIPE_NOT_AVAILABLE kanssa, kun DC vastaa.

Tämä ongelma ilmenee yleensä järjestelmissä, jotka edellyttävät paljon SID-hakuja toimialueen ohjauspalvelimessa. Jos ympäristössä on orpoja SID-tunnisteita, sillä on taipumus kirjata paljon enemmän näitä virheitä. Tämä johtuu ohjauslaitteeseen lähetettävän liikenteen määrästä, ja joka kerta, kun käyttöoikeusluetteloa käytetään, meidän on lähetettävä ohjauskoneelle pyyntö pyytää kaikkien SID-tunnisteiden identiteettiä, joita meillä ei ole SID-välimuistissamme. Orvot SID:t eivät ole koskaan SID-välimuistissa, ja niitä yritetään etsiä joka kerta, kun lsarpc-nimiselle putkelle on tehtävä aukkojen määrää.

Kun ensimmäinen avoin yritys onnistuu, tämä on vaikuttamaton tapahtuma ja nämä viestit voidaan jättää huomiotta.

Pysyvä korjaus:
Tekninen osasto on tietoinen ongelmasta ja pyrkii korjaamaan sen tulevassa koodiversiossa. Tämä on häiriötön ongelma, ja se voidaan turvallisesti jättää huomiotta sillä välin. Jos kuitenkin haluat yrittää vähentää tai poistaa viestin, käytettävissä on joitakin kiertotapoja.

Vaihtoehtoinen menetelmä 1:
Voit yrittää estää näiden ilmoitusten näkymisen lokeissa muutamalla eri tavalla. Koska ongelma johtuu useista samanaikaisista avoimista yrityksistä lsarpc-putkessa, helpoin tapa vähentää viestejä on vähentää tarvittavien SID-hakujen määrää.

Orvot SID:t aiheuttavat näitä liiallisia hakuja. Seuraavaa parametria voidaan muokata pakottamaan haut etsimään secmap-välimuistia tuntemattomille sid:ille, minkä pitäisi vähentää ohjauskoneeseen menevän liikenteen määrää:

[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v
server_2 :
name                    = acl.mappingErrorAction
facility_name           = cifs
default_value           = 8
current_value           = 8
configured_value        = 8
user_action             = none
change_effective        = immediate
range                   = (0,31)
description             = Define rules for an unknown SID/UID/GID mapping

detailed_description
Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID

Tämä tarkoittaa seuraavia tietoja:
Bit0 = Tallentaa tuntemattoman sid.
Bit1 = Tallentaa sid-tunnuksen ilman UNIX-määritystä.
Bit2 = Ottaa virheenkorjausjäljitykset käyttöön.
Bit3 = Tee haku vain välimuistista (secmap- tai globalSid-välimuistista tai yhteyskohtaisesta SID-välimuistista)

Jos bitit 0 ja 1 asetetaan (0x3 arvona), orvot SID: t voidaan tallentaa tiedostojärjestelmän käyttöoikeusluetteloihin (oletusarvoisesti ne eivät ole.). Olisi suositeltavaa muuttaa arvo arvosta 0x3 arvoon 0x11, tämä käynnistää bitin 0,1 ja 3. Tämä tarkoittaa, että tallenna tuntemattomat SID-tunnukset ilman unix-kartoitusta ja etsi vain secmap- ja globaaleja SID-välimuistia. Jos asetuksena on 0x8 tai jokin muu yhdistelmä, jossa bitit 0 ja 1 on poistettu käytöstä, orpoja sid-tunnuksia ei saa tallentaa eikä tätä parametria saa muuttaa.

Jos haluat muokata parametria, voit suorittaa seuraavan komennon:

server_param server_2 -f cifs -m acl.mappingErrorAction -v 11

Tämä todennäköisesti vähentää esiintymiä, mutta voi poistaa ne kokonaan tai ei.

Vaihtoehtoinen menetelmä 2:
Varma tapa päästä eroon lokeissa olevista virheistä on palauttaa ohjauskoneen tietoliikennekäyttäytyminen tilaan, jossa se oli ennen uusia koodeja (eli puhumme vain SMB1:n toimialueen ohjauskoneille).

Jos haluat palata käyttämään ohjauskoneen SMB1-toimintoa (vanha VNX-toiminto), ota yhteyttä Dellin tukeen ja tutustu tähän tietämyskannan artikkeliin.