[ English | English (United Kingdom) | 中文 (简体, 中国) | Indonesia | русский | français | नेपाली | Deutsch | Esperanto | português (Brasil) | español | 한국어 (대한민국) ]

Paramétrer le stockage de session pour le Dashboard

Le Dashboard utilise Le framework Django pour gérer les données de session des utilisateurs. Cependant, vous pouvez utiliser n’importe quel back end de session disponible. Vous pouvez personnaliser le back end de session grâce au paramètre SESSION_ENGINE dans le fichier local_settings.py.

Après avoir architecturé et implémenté les services primordiaux d’OpenStack et les autres services requis, combinés avec les services du Dashboard, les utilisateurs et les administrateurs peuvent alors utiliser le Dashboard OpenStack. Référerez au chapitre Documentation Utilisateur OpenStack du Guide Openstack de l’Utilisateur Final pour plus d’instructions pour se connecter au Dashboard.

La section suivante décrit les pour et les contre de chaque option dans le déploiement du Dashboard.

Cache en mémoire locale

Le stockage en mémoire locale est le paramétrage le plus rapide et le plus simple à mettre en place, puisqu’il n’a aucune autre dépendance. Il a les importants désavantages suivants:

  • Pas de stockage partagé entre processus ou nœuds.

  • Pas de persistance lorsqu’un processus se termine.

Le backend local de mémoire est autorisé par défaut pour Horizon uniquement parce qu’il n’a aucune dépendence. Ce n’est pas recommandé une utilisation en production.

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
  'default' : {
    'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'
  }
}

Vous pouvez utiliser des application comme Memcached ou Redis pour du caching externe. Ces applications offrent persistance et un stockage partagé et sont utilises pour des déploiement de petite taille.

Memcached

Memcached is a high-performance and distributed memory object caching system providing in-memory key-value store for small chunks of arbitrary data.

Exigences:

  • Le service en Memcache tourne et est accessible.

  • Le module Python python-memcached est installé.

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
  'default': {
    'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
    'LOCATION': 'my_memcached_host:11211',
  }
}

Redis

Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server.

Exigences:

  • Le service en Redis tourne et est accessible.

  • Les module Pythons redis et ``django-redis``sont installés.

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    "default": {
        "BACKEND": "redis_cache.cache.RedisCache",
        "LOCATION": "127.0.0.1:6379:1",
        "OPTIONS": {
            "CLIENT_CLASS": "redis_cache.client.DefaultClient",
        }
    }
}

Initialisez et configurez la base de données

Les sessions soutenues par des bases de données sont scalables, persistantes et peuvent être rendues hautement concurrentielles et disponibles.

However, database-backed sessions are one of the slower session storages and incur a high overhead under heavy usage. Proper configuration of your database deployment can also be a substantial undertaking and is far beyond the scope of this documentation.

  1. Démarrer le client en ligne de commande de MySQL.

    # mysql
    
  2. Entrez le mot de passe de l’utilisateur root de MySQL lorsqu’il est demandé.

  3. Pour configurer la base de données MySQL, créer la base de données dash.

    mysql> CREATE DATABASE dash;
    
  4. Créez un utilisateur MySQL qui a tous les droits sur la base de données dash fraîchement crée. Remplacez DASH_DBPASS par un mot de passe pour le nouvel utilisateur.

    mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'%' IDENTIFIED BY 'DASH_DBPASS';
    mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'localhost' IDENTIFIED BY 'DASH_DBPASS';
    
  5. Tapez ``quit``dans le prompt ``mysql>``pour sortir de MySQL

  6. Dans le fichier local_settings.py, mettez à jour les options suivantes:

    SESSION_ENGINE = 'django.contrib.sessions.backends.db'
    DATABASES = {
        'default': {
            # Database configuration here
            'ENGINE': 'django.db.backends.mysql',
            'NAME': 'dash',
            'USER': 'dash',
            'PASSWORD': 'DASH_DBPASS',
            'HOST': 'localhost',
            'default-character-set': 'utf8'
        }
    }
    
  7. Après avoir configuré le fichier local_settings.py comme montré, vous pouvez exécuter la commande manage.py migrate pour peupler cette nouvelle base de données.

    # /usr/share/openstack-dashboard/manage.py migrate
    
  8. Pour éviter un warning lorsque vous redémarrer Apache sur Ubuntu, créez un dossier trou_noir dans le dossier du Dashboard comme suit.

    # mkdir -p /var/lib/dash/.blackhole
    
  9. Redémarrez le service Apache.

  10. Sur Ubuntu, redémarrez le service nova-api pour assurer que le serveur API peu se connecter au Dashboard sans erreur.

    # service nova-api restart
    

Base de donnée cache

To mitigate the performance issues of database queries, you can use the Django cached_db session back end, which utilizes both your database and caching infrastructure to perform write-through caching and efficient retrieval.

Autorisez ce paramètre hybride en configurant votre base de données et votre cache, comme indiqué précédemment. Ensuite, fixez la valeur suivante:

SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"

Cookies

Si vous utilisez Django 1.4 ou supérieur, le backend ``signed_cookies``évite des problèmes de charge et de passage à l’échelle du serveur.

Ce backend stocke les données de session dans un cookie, qui est stocké par le navigateur de l’utilisateur. Le backend utilise une technique de signature cryptographique pour assurer que les données de session ne soient pas altérées lors du transport. Ce n’est pas du chiffrement. Les données de sessions sont toujours lisibles par un attaquant.

Les avantages de ce moteur c’est qu’il ne demande pas de dépendances additionnelles ni de couche supplémentaire d’infrastructure et qu’il passe à l’échelle indéfiniment du moment que la quantité de données de sessions stockées peut être contenue dans un cookie normal.

Le plus gros désavantage est qu’il place les données de session dans du stockage sur la machine de l’utilisateur et les transporte au travers du câble. Ceci limite entre autres la quantité de données de session qui peuvent être stockées.

Voir la documentation de Django sur les sessions par cookie.