2017-02-22 2 views
3

Les informations d'identification d'une application nouvellement déployée sont rejetées par MongoDB avec "Échec de l'authentification". Le gestionnaire d'opérations MongoDB est bloqué sur "AdjustUsers" pendant quelques heures déjà.L'application ne parvient pas à se connecter à MongoDB Enterprise avec "Authentification échouée" et le gestionnaire Ops bloqué dans "AdjustUsers"


Vérifié par:

cf service-connector 8080 opsmanager.service.consul:8080 

Navigateur ouvert à http://localhost:8080 et connectez-vous en utilisant la clé de service de MongoDB obtenu sur le portail:

"ops_manager_url": "http://opsmanager.service.consul:8080", 
"ops_manager_user": "xxx", 
"ops_manager_password": "xxx", 

J'ai récemment restauré autour 20GB de données, en utilisant mongorestore:

cf service-connector 27020 xxx-0.service.consul:33602 
mongorestore --gzip --port 27020 --username xxx --password xxx --db rs_xxx /backup/mongodump/ > mongorestore.log 2>&1 & 

D'autres applications déjà existantes n'ont pas de problème. Seule une application que je déployé à l'aide de déploiement bleu-vert ne parvient pas à se connecter:

cf push $APP-new 
cf map-route $APP-new $DOMAIN --hostname $APP 
cf unmap-route $APP $DOMAIN --hostname $APP || true 
cf unmap-route $APP-new $DOMAIN --hostname $APP-new 
cf delete -f $APP 
cf rename  $APP-new $APP 

Dans mes applications je ne précise pas WriteConcern, je suppose qu'il est seulement primaire (« w: 1 »)

Répondre

2

Avec cf bind-service ou cf unbind-service, le Servicebroker (composant Cloud Foundry) crée de nouvelles informations d'identification générées de manière aléatoire (voir cf env $APP). Avec notre offre de service MongoEnterprise, Service Broker se connecte à l'API Ops Manager et déploie un nouvel utilisateur sur le réplicas mongod.

enter image description here

Lorsque Ops Manager déploie l'utilisateur (createUser) il utilise WriteConcern « majorité », ce qui signifie au moins un des besoins secondaires à reconnaître l'écriture.

COMMAND [conn53768] command rs_$DBNAME.$cmd command: createUser { createUser: "$USERNAME", pwd: "xxx", digestPassword: false, roles: [ { role: "readWrite", db: "rs_$DBNAME" } ], writeConcern: { w: "majority" } } keyUpdates:0 writeConflicts:0 numYields:0 reslen:138 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { W: 2 } }, Collection: { acquireCount: { w: 2 } } } protocol:op_query 9811ms 

En raison du mongorestore, qui a été réalisée quelques heures avant que ce problème est survenu, il y a une possibilité que la commande createUser était hors délai en raison du manque de reconnaissance des secondaries qui étaient des indices de construction occupés au premier plan et arrière-plan. La construction de l'index (options mongorestore par défaut) est d'abord effectuée sur le primaire et, lorsqu'elle est terminée, sera en cours dans les secondaires. Ceci explique l'augmentation du retard sur les secondaires au cours de createUser.

Les générations d'index peuvent prendre beaucoup de temps, en fonction de l'index et de la taille des données. Nous avons entendu beaucoup de clients se plaindre de la construction de l'index prendre trop de temps.

Voici les journaux de la construction de l'index. Dans Ops Manager, le client peut voir streamé mongodb.log (opsmanager.service.consul) avec un peu de retard de la part de tous les membres du jeu de réplicas.

... 
2017-02-15T10:40:06.199+0000 I INDEX [repl writer worker 10] build index done. scanned 1108917 total records. 672 secs 
2017-02-15T10:50:08.553+0000 I INDEX [repl writer worker 4] build index done. scanned 1108917 total records. 602 secs 
2017-02-15T11:01:13.888+0000 I INDEX [repl writer worker 7] build index done. scanned 1108917 total records. 665 secs 
... 
2017-02-15T15:01:37.405+0000 I INDEX [repl index builder 176] build index done. scanned 1109531 total records. 659 secs 
2017-02-15T15:01:37.406+0000 I INDEX [repl index builder 170] build index done. scanned 1109531 total records. 659 secs 
2017-02-15T15:16:20.139+0000 I INDEX [repl index builder 170] build index done. scanned 1109699 total records. 882 secs 

Ce sont les erreurs de Automation Agent (Ops directeur parle via HTTP avec l'agent Autoamtion sur la gestion VM, l'agent d'automatisation parle alors avec mongod avec protocole natif)

[2017/02/15 13:33:36.297] [.error] [cm/mongoctl/authctl.go:updateUser26Style:697] [101] <rs_$DB_NAME> [13:33:36.297] Error updating 2.6-style user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2) in db = rs_$DB_NAME : <rs_$DB_NAME> [13:33:36.297] Timed out (timeout=-1ns) trying to runCommandWithTimeout(dbName=rs_$DB_NAME, cmd=[{"Name":"updateUser","Value":"$USER"},{"Name":"pwd","Value":"$PASSWORD"},{"Name":"digestPassword","Value":false},{"Name":"roles","Value":[{"db":"rs_$DB_NAME","role":"readWrite"}]}]) 
[2017/02/15 13:33:36.297] [.error] [cm/mongoctl/authctl.go:UpsertUser:516] [101] <rs_$DB_NAME> [13:33:36.297] Error upserting 2.6-style user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2) : <rs_$DB_NAME> [13:33:36.297] Error updating 2.6-style user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2) in db = rs_$DB_NAME : <rs_$DB_NAME> [13:33:36.297] Timed out (timeout=-1ns) trying to runCommandWithTimeout(dbName=rs_$DB_NAME, cmd=[{"Name":"updateUser","Value":"$USER"},{"Name":"pwd","Value":"$PASSWORD"},{"Name":"digestPassword","Value":false},{"Name":"roles","Value":[{"db":"rs_$DB_NAME","role":"readWrite"}]}]) 
[2017/02/15 13:33:36.297] [.error] [cm/action/adjustusers.go:adjustUsers:52] [101] <rs_$DB_NAME> [13:33:36.297] Error upserting user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2). Trying to proceed though. : <rs_$DB_NAME> [13:33:36.297] Error upserting 2.6-style user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2) : <rs_$DB_NAME> [13:33:36.297] Error updating 2.6-style user = AuthUser([email protected]_$DB_NAME,roles=AuthRoles(1:{"Rolename":"readWrite","Db":"rs_$DB_NAME"}),interned=true,identity=2) in db = rs_$DB_NAME : <rs_$DB_NAME> [13:33:36.297] Timed out (timeout=-1ns) trying to runCommandWithTimeout(dbName=rs_$DB_NAME, cmd=[{"Name":"updateUser","Value":"$USER"},{"Name":"pwd","Value":"$PASSWORD"},{"Name":"digestPassword","Value":false},{"Name":"roles","Value":[{"db":"rs_$DB_NAME","role":"readWrite"}]}]) 
[2017/02/15 13:33:36.381] [.error] [cm/executor/executor.go:ExecutePlan:184] <rs_$DB_NAME> [13:33:36.381] Postcondition failed for step AdjustUsers because 
[The value of 'currentState.UsersRight' = false, but it should be true]. Outcome=3 

Résumé: tout avec WriteConcern primaire fonctionne bien, mais WriteConcern fois majoritaire, ce qui bloque les builds d'index.

1

Une façon de noter que le db contraignant n'a pas réussi est en testant l'application nouvellement déployée avant un mappage et la suppression de l'ancien (bilan de santé au niveau de l'application):

cf push $APP-new 
# only old app active 

# test new app 
curl --fail --silent --output /dev/null https://$APP-new.$DOMAIN/status 

cf map-route $APP-new $DOMAIN --hostname $APP 
# both apps active 
cf apps 
cf routes 

cf unmap-route $APP $DOMAIN --hostname $APP || true 
# only new app active 

cf unmap-route $APP-new $DOMAIN --hostname $APP-new 
cf delete -f $APP 
cf rename  $APP-new $APP 

cf apps 

Cet exemple suppose que le nom de l'application est le même que le nom d'hôte.