General:Concepts

From Wiki_dbSQWare
Jump to: navigation, search

Generality

Limitations of this section

this section Cette section does not claim to handle all possible configuration cases of dbSQWare but will allow you to understand the general structure of the tool, interconnection between modules, the principles of personalization, …

For any kind of information, web site

(Visitez le wiki dbSQWare français, WikiFr)

Before running into the installation, please read the section « Base Installation », this will allow you to make a standard installation of dbSQWare.

dbSQWare, what is it ?

dbSQWare allows you to unite the use of databases Oracle, Sybase, SqlServer, MySQL, DB2, PostgreSQL, MongoDB, Cassandra, … thanks to a common and homogeneous base. The design of this platform provides great flexibility of use, of personalization and a unified approach to the exploitation and rendering of indicators on all types of DBMS managed by the tool.
It is neither an administration tool nor a monitoring tool (not a monitoring tool but a complement to it).

The product is intended (for its scripting part) for environments Unix/Linux only because it is essentially written in shell ksh and sql (MsSql too is fully managed from depuis unix thanks to a FreeTds connection, for more information http://www.freetds.org/). The web part, for its part, is written in PHP and javascript (jQuery).
For DBMS other than MsSql and installed on a Windows host, many functionalities (but not all) are accessible with a distant SQL connection (for the scripts supporting that).

List DBMs supported at this time :

  • Oracle
  • Sybase (ASE and RS)
  • MySQL
  • MsSql
  • MongoDB
  • DB2
  • PostgreSQL
  • Teradata
  • Cassandra
  • Adabas
  • Ingres


A search for “Homogeneity”

In use :

  • Consistent use, whatever the DBMS
  • Easy adaptation using configuration files and/or passing arguments
  • A single version of the tool for the entire fleet (synchronization by rsync)
  • The scripts adapt to the version of the DBMS processed (a single script for an action. Example : the script for oracle indicators supports from v7 to 19c multitenant architecture)
  • Launch without arguments
  • Online help (arguments and examples)
  • Dry run mode for validate the syntax (flag -Exec for the execution)


In the development and evolutions :

  • Homogeneous design for all DBMS
  • Code standardization (names, functions, structures, parsing of arguments, online help, …)
  • Generic multi-engine libraries
  • Modification of behavior by overloading libraries
  • Set of standard shell libraries that can be integrated into custom scripts


General structure of the tool

dbSQWare is composed of four complementary modules.

SQWareProduction is the local exploitation module (or remotely for 80% of the functionalities) of the DBMs. It makes possible to manage the operations in the broad sense of DBMS :

  • Backup
  • Restorations
  • Statistics
  • Alerts reporting
  • Job launch encapsulation
  • Running unix commands in parallel
  • ...

This module gather also a certain number of indicators which are uploaded to the repository of databases SQWareRepository. this module is made of a part for each managed DBMS and a core part including a set of settings and functions generic to all DBMS. the scripts are all written according to the same development standard (parsing of arguments, online help, mail on error, ascent of indicators into SQWareRepository, …).

SQWareRepository is the module for the management of the repository and indicators in the database :
It allows you to manage the repository as well as the indicators stored in databases.
It's a MySQL database (>= 5.6) or MariaDB (>= 10.1), with generic tables as well as specific tables depending on the DBMS processed.

SQWareCentral est le module central de l’outil. Il permet de gérer l'ensemble du parc depuis ce point central :

  • Collectes centralisées d’indicateurs
  • Déploiement de SQWareProduction par rsync
  • Gestion de recherche « full text » dans les référentiels
  • Connexion simplifiée par ssh aux différentes instances du parc…
  • Génération de fichier CMDB
  • Check centralisé des indicateurs


Ce module se base entre autres sur le référentiel, SQWareRepository (génération dynamique des listes d’instances à traiter, …).
Il est composé d’une partie « core », commune à tous les SGBD exploités et d’un plugin spécifique pour chaque SGBD (Oracle, Sybase, MsSql, MySQL, DB2, PostgreSQL, MongoDB, Cassandra, …).
En général, l’installation du point central se fait sur une VM Rocky Linux release 8.8 (Green Obsidian) 64 bits (2 vCPU et 4 Go de RAM). Vous pouvez évidemment l’installer sur un autre type de Linux/Unix.

SQWareWeb est le module de restitution graphique web des indicateurs :
Il fonctionne avec apache 2.x et est écrit en PHP (support en principe de 5.x à 7.x), javascript (jQuery).
Il permet de faire la présentation des indicateurs et capacity planning sous forme :

  • Graphiques (javascript)
  • Tableaux (avec tri, filtrage et formatage en local sur le navigateur)
  • Exports Excel
  • ...


Il se base entièrement sur les données contenues dans le référentiel de base de données SQWareRepository.
Aucune connexion aux bdd clientes, l’interface ne sert qu’à la restitution des indicateurs et au paramétrage du référentiel.
Les restitutions sont présentées sensiblement de la même façon quel que soit le SGBD (aux spécificités près de celui-ci), ce qui rend plus agréable et plus aisée la navigation.
Ce module est composé d’une partie « core », commune à tous les SGBD gérés, (moteur de templates, affichage graphiques, tableaux, ...) et d’un plugin spécifique pour chaque SGBD.

Normalisation

Une des bases de « l’homogénéité » passe par de la normalisation et la généricité.

Convention de nommage

Arborescences

Arborescences générales (sur le point central) : 

…/dbSQWare/SQWareProduction/… 	=> arborescence du module SQWareProduction.
…/dbSQWare/SQWareRepository/… 	=> arborescence du module SQWareRepository.
…/dbSQWare/SQWareCentral/… 	=> arborescence du module SQWareCentral.
…/dbSQWare/SQWareWeb/… 		=> arborescence du module SQWareWeb.


Ensuite, pour le niveau sous les modules, il existe un répertoire « generic » contenant tout ce qui est multi-sgbd et un répertoire par sgbd supporté.
Voici ce que cela donne : 

cassandra	=> spécifique pour Cassandra
db2		=> spécifique pour DB2
generic 	=> générique à tous les moteurs
ingres		=> spécifique pour Ingres
mongodb 	=> spécifique pour MongoDB
mssql		=> spécifique pour MsSql
mysql		=> spécifique pour MySQL
oracle		=> spécifique pour Oracle
postgres	=> spécifique pour PostgreSQL
sybase		=> spécifique pour Sybase ASE
sybrep		=> spécifique pour Sybase RS
teradata	=> spécifique pour teradata
adabas          => spécifique pour adabas


Puis, pour les arborescences contenant des scripts, vous trouverez des répertoires comme suivant. Les répertoires de la forme *_cust sont dédiés à la customisation de votre environnement, autant que possible, ne touchez qu’aux scripts et fichiers de configuration de ces arborescences, cela vous facilitera les mises à jours de l’outil (sauf bug spécifique, il n’y a pas de raison de toucher aux arborescences standards si vous suivez les préconisations de personnalisation).
Contenu des répertoires : 

bin		=> scripts standards
bin_cust	=> scripts customs pour votre environnement
etc		=> fichiers standards de configuration (variables globales)
etc_cust	=> fichiers customs de configuration (surchargent les standards)
help		=> fichiers standards d’aide
help_cust	=> fichiers customs d’aide pour votre environnement
lib		=> librairies standards de fonctions shell
lib_cust	=> librairies customs de fonctions shell (surchargent les standards)
tools		=> scripts standards utilisés ponctuellement
tools_cust	=> scripts customs utilisés ponctuellement pour votre environnement
menu		=> menus (shell) standards
menu_cust	=> menus customs pour votre environnement


Voici donc, par exemple, ce que cela donne pour SQWareProduction Oracle et Générique : 

SQWareProduction/oracle
SQWareProduction/oracle/bin
SQWareProduction/oracle/bin_cust
SQWareProduction/oracle/etc
SQWareProduction/oracle/etc_cust
SQWareProduction/oracle/help
SQWareProduction/oracle/help_cust
SQWareProduction/oracle/lib
SQWareProduction/oracle/lib_cust
SQWareProduction/oracle/menu
SQWareProduction/oracle/menu_cust
SQWareProduction/oracle/tools
SQWareProduction/oracle/tools_cust
SQWareProduction/generic
SQWareProduction/generic/bin
SQWareProduction/generic/bin_cust
SQWareProduction/generic/etc
SQWareProduction/generic/etc_cust
SQWareProduction/generic/lib
SQWareProduction/generic/lib_cust
SQWareProduction/generic/tools
SQWareProduction/generic/tools_cust


Fichiers (arborescence scripts)

La majorité des fichiers sont nommés avec un préfixe de la forme : 

sqwora_*	=> pour Oracle
sqwsyb_*	=> pour Sybase ASE
sqwrs_* 	=> pour Sybase RS
sqwmys_*	=> pour Mysql
sqwmsq_*	=> pour Mssql
sqwdb2_*	=> pour DB2
sqwpg_* 	=> pour PostgreSQL
sqwter_*	=> pour Teradata
sqwcas_*	=> pour Cassandra
sqwada_*	=> pour Adabas
sqwing_*	=> pour Ingres
sqwgen_*	=> pour les génériques (multi SGBD)
sqwctl_*	=> pour ceux du module SQWareCentral


La majorité des fichiers sont nommés avec un suffixe de la forme : 

*.ksh	=> pour les scripts shell
*.cfg	=> pour les fichiers de configuration (variables globales)
*.lib	=> pour librairies de fonctions shell
*.hlp	=> pour les fichiers d’aide


Fichiers (arborescence web)

La majorité des fichiers sont nommés avec un suffixe de la forme : 

*.php	=> pour les scripts PHP
*.js	=> pour les scripts javascript
*.chart	=> pour les fichiers de paramétrage des graphiques
*.table	=> pour les fichiers de paramétrage des tableaux


Contenu des scripts shell

En général, la convention suivie dans les scripts shell est la suivante : 

gvsqw_*{}	=> variable globale initialisée par l’environnement et/ou une librairie générique
lvsqw_*{}	=> variable locale initialisée par le script et/ou une librairie spécifique
gfsqw_*{}	=> fonction définie par une librairie générique
lfsqw_*{}	=> fonction définie par le script et/ou une librairie spécifique


Objets bdd (SQWareRepository)

Les objets préfixés par tsqw_% or isqw_% sont génériques à tous les moteurs. Les objets préfixés par tsqwXXX_% or isqwXXX_% sont spécifiques pour un SGBD particulier (exemple : tsqwcas_% or isqwcas_% pour Cassandra).

Noms des objets génériques : 

tsqw_%  	=> pour les tables
isqw_%		=> pour les indexes
isqw_%_u	=> pour les indexes uniques
isqw_%_pk	=> pour les primary keys


Noms des objets spécifiques : 

tsqwXXX_%	=> pour les tables
isqwXXX_%	=> pour les indexes
isqwXXX_%_u	=> pour les indexes uniques
isqwXXX_%_pk	=> pour les primary keys


Exemple du spécifique pour Cassandra : 

tsqwcas_%	=> pour les tables
isqwcas_%	=> pour les indexes
isqwcas_%_u	=> pour les indexes uniques
isqwcas_%_pk	=> pour les primary keys


Principe de surcharge

Attention, cette section est une partie essentielle pour paramétrer dbSQWare sans remettre en cause les prochains patches/upgrades. Comme expliqué dans la section précédente, il ne faut pas toucher aux fichiers des arborescences standards, mais utiliser les répertoires de type *_cust pour faire votre customisation.
Lors d’un patch/upgrade, on extrait l’archive dbSQWare_full_latest.tgz par-dessus l’arborescence installée, ce qui écrase les fichiers standards avec la nouvelle version mais conserve vos customisations !
Le principe de base de la surcharge est de créer un fichier de même nom que dans l’arborescence (XXX) standard dans l’arborescence (XXX_cust) et d’y redéclarer la/les variables/librairies nécessaire(s).
Ne déclarez que le strict nécessaire pour le fonctionnement sur votre environnement (inutile de tout déclarer comme pour une configuration bdd).

Personnalisation des variables

Le fichier essentiellement mis à jour pour les variables est sqwgen_GlobalVar.cfg, nous le prendrons donc comme exemple.
Le principe suivant se base sur $gvsqw_GenPath qui représente le path du script exécuté et sur ${gvsqw_RdbmsRoot} qui représente le trigramme (en minuscule) du SGBD sur lequel tourne le script et $gvsqw_RdbmsType, le répertoire spécifique du SGBD. Voir le paragraphe sur les règles de nommage pour les noms de fichiers réels.

Principe général du source en cascade (si les fichiers existent, 6 niveaux) : 

# Fichier generic standard => pour tout le parc
$gvsqw_GenPath/../../generic/etc/sqwgen_GlobalVar.cfg

# Fichier generic custom => pour tout le parc
$gvsqw_GenPath/../../generic/etc_cust/sqwgen_GlobalVar.cfg

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwgen_GlobalVar.cfg

# Fichier spécifique sgbd standard => pour tout le parc
$gvsqw_GenPath/../../$gvsqw_RdbmsType/etc/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg

# Fichier spécifique sgbd custom => pour tout le parc
$gvsqw_GenPath/../../$gvsqw_RdbmsType/etc_cust/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg

# Fichier spécifique sgbd pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg


Exemple pour SQWareProduction Oracle installé dans le $HOME : 

# Fichier generic standard => pour tout le parc
$HOME/SQWareProduction/../../generic/etc/sqwgen_GlobalVar.cfg

# Fichier generic custom => pour tout le parc
$HOME/SQWareProduction/../../generic/etc_cust/sqwgen_GlobalVar.cfg

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwgen_GlobalVar.cfg

# Fichier spécifique sgbd standard => pour tout le parc
$HOME/SQWareProduction/../../oracle/etc/sqwora_GlobalVar.cfg

# Fichier spécifique sgbd custom => pour tout le parc
$HOME/SQWareProduction/../../oracle/etc_cust/sqwora_GlobalVar.cfg

# Fichier spécifique sgbd pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwora_GlobalVar.cfg


Template:Note

Personnalisation des fonctions shell

En principe, sauf cas d’utilisation avancé de dbSQWare, vous n’avez pas besoin de personnaliser les fonctions, la surcharge de variables ou le passage d’options est suffisant dans la grosse majorité des cas (plus de 99%).
Attention, la customisation de fonction demande un minimum de compétences en shell et une analyse d’impact sur le fonctionnement futur des scripts. Nous vous conseillons de vous faire assister par le support, au moins pour la première fois.

La majorité des scripts des arborescences …/bin/ sourcent (grâce à la fonction gfsqw_SourceOverLoadLibs) les librairies du même nom que le script, en remplaçant .ksh par .lib (exemple : yyy.ksh va sourcer yyy.lib).

Dans l’explication suivante des sources en cascade de librairies, voici à quoi correspondent les variables : 

gvsqw_GenPath => path du script exécuté
lvsqw_Lib     => librairie que l’on souhaite charger (exemple sqwora_Global.lib)
lvsqw_LibGen  => nom générique, on remplace dans lvsqw_Lib le trigramme spécifique au SGBD par gen (exemple sqwgen_Global.lib)


Principe général du source en cascade (si les fichiers existent, 10 niveaux) : 

# Librairie generic standard => pour tout le parc
$gvsqw_GenPath/../../generic/lib/$lvsqw_LibGen

# Librairie generic custom => pour tout le parc
$gvsqw_GenPath/../../generic/lib_cust/$lvsqw_LibGen

# Librairie spécifique sgbd standard => pour tout le parc
$gvsqw_GenPath/../lib/$lvsqw_LibGen

# Librairie spécifique sgbd custom => pour tout le parc
$gvsqw_GenPath/../lib_cust/$lvsqw_LibGen

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/$lvsqw_LibGen

# Librairie generic standard => pour tout le parc
$gvsqw_GenPath/../../generic/lib/$lvsqw_Lib

# Librairie generic custom => pour tout le parc
$gvsqw_GenPath/../../generic/lib_cust/$lvsqw_Lib

# Librairie spécifique sgbd standard => pour tout le parc
$gvsqw_GenPath/../lib/$lvsqw_Lib

# Librairie spécifique sgbd custom => pour tout le parc
$gvsqw_GenPath/../lib_cust/$lvsqw_Lib

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/$lvsqw_Lib


Exemple pour sqwora_ParallelRun.ksh de SQWareProduction Oracle installé dans le $HOME : 

# Librairie generic standard => pour tout le parc
$HOME/SQWareProduction/../../generic/lib/sqwgen_ParallelRun.lib

# Librairie generic custom => pour tout le parc
$HOME/SQWareProduction/../../generic/lib_cust/sqwgen_ParallelRun.lib

# Librairie spécifique sgbd standard => pour tout le parc
$HOME/SQWareProduction/../lib/sqwgen_ParallelRun.lib

# Librairie spécifique sgbd custom => pour tout le parc
$HOME/SQWareProduction/../lib_cust/sqwgen_ParallelRun.lib

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwgen_ParallelRun.lib

# Librairie generic standard => pour tout le parc
$HOME/SQWareProduction/../../generic/lib/sqwora_ParallelRun.lib

# Librairie generic custom => pour tout le parc
$HOME/SQWareProduction/../../generic/lib_cust/sqwora_ParallelRun.lib

# Librairie spécifique sgbd standard => pour tout le parc
$HOME/SQWareProduction/../lib/sqwora_ParallelRun.lib

# Librairie spécifique sgbd custom => pour tout le parc
$HOME/SQWareProduction/../lib_cust/sqwora_ParallelRun.lib

# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwora_ParallelRun.lib


Template:Note

Interopérabilité des modules

Communications entre les modules

Depuis SQWareProduction

SQWareProduction est le seul module se connectant directement aux bases de données clientes.
Il permet ensuite notamment de remonter un certain nombre d’indicateurs dans SQWareRepository (en passant par un tampon local).
C'est SQWareCentral qui vient chercher les données dans le tampon de SQWareProduction par rsync.

Depuis SQWareRepository

SQWareRepository étant une database MySQL (>= 5.6) ou MariaDB (>= 10.1), aucun flux n’est à son initiative.

Depuis SQWareCentral

SQWareCentral se connecte à SQWareRepository pour générer les listes d’instances à traiter.
Il permet de lancer des commandes SQWareProduction au travers d’une connexion ssh.
Il permet également le déploiement des scripts SQWareProduction ainsi que la récupération des traces SQWareProduction par rsync.
Pré-requis :

  • Package rsync sur le point central et les clients SQWareProduction
  • Flux ssh vers les clients SQWareProduction (TCP port 22 vers les clients SQWareProduction)
  • Flux vers le repo MySQL/MariaDB (en général les deux modules sont sur la même machine)


Depuis SQWareWeb

SQWareWeb se connecte à SQWareRepository qui contient les indicateurs (aucune connexion vers les bases clientes).
Pré-requis :

  • Packages httpd php php-pdo php-mysql
  • Flux vers le repo MySQL/MariaDB (en général les deux modules sont sur la même machine)


Matrice de flux

Cette section ne couvre pas tous les cas possibles, mais doit vous permettre de faire ouvrir les flux nécessaires en cas de présence de FW.

Type Nombre Source Destination Port (courant) Commentaire
Toujours x SQWareCentral SQWareProduction 22 Rsync sources + exec à distance
Spécifique Ora x SQWareProduction
sur CentralHost		 bdd Oracle 1521 Lorsque l'on souhaite collecter les rapports AWR depuis le point central.
Autant de fois qu'il y a de bdd Oracle.
Spécifique Msq x SQWareProduction
sur CentralHost		 bdd MsSql 1433 Lorsque l'on souhaite gérer tous les MsSql depuis le point central.
Peut-être aussi installé sur une autre machine que le pont central.
... x CentralHost toute bdd 1521, 1433, 5432, ... Lorsque l'on souhaite accéder aux instances depuis le point central en SQL.
Ce besoin est pur DBA et non nécessaire à dbSQWare.
Distribué 1 SQWareCentral SQWareRepository 3306 Quand la base MySQL/MariaDB du repo n'est pas sur le point central (rare)
Distribué 1 SQWareWeb SQWareRepository 3306 Quand la base MySQL/MariaDB du repo n'est pas sur le point central (rare)
ou que SQWareWeb n'est pas sur le point central (rare)

Liens utiles

Voici les liens utiles pour dbSQWare:


Rejoignez le groupe dbSQWare sur viadéo:
http://www.viadeo.com/groups/?containerId=002dcbr792acawk

Rejoignez le groupe dbSQWare sur Linkedin:
http://www.linkedin.com/groups?gid=3683269

Retrieved from "https://wiki.dbsqware.com/index.php?title=General:Concepts&oldid=27195"