Si vous avez suivi Microsoft récemment, il ne sera pas surprenant que le fournisseur d'un produit de base de données concurrent, à savoir SQL Server, ait également sauté dans le train PostgreSQL. De la libération de 60 000 brevets à OIN au sponsor Platinum de PGCon, Microsoft est l'une des organisations de soutien aux entreprises PostgreSQL. A profité de chaque occasion pour montrer que non seulement vous pouvez exécuter PostgreSQL sur Microsoft, mais que l'inverse est également vrai :Microsoft, grâce à son offre cloud, peut exécuter PostgreSQL pour vous. La déclaration est devenue encore plus claire avec l'acquisition de Citus Data et la sortie de leur produit phare dans le Cloud Azure sous le nom d'Hyperscale. Il est prudent de dire que l'adoption de PostgreSQL est en croissance et qu'il existe maintenant encore plus de bonnes raisons de le choisir.
Mon parcours dans le cloud Azure a commencé dès la page de destination où j'ai rencontré les concurrents :un serveur unique et une version préliminaire (en d'autres termes, aucun SLA fourni) d'Hyperscale (Citus). Ce blog se concentrera sur le premier. Au cours de ce voyage, j'ai eu l'occasion de pratiquer ce qu'est l'open source - redonner à la communauté - dans ce cas, en fournissant des commentaires à la documentation qui, au crédit de Microsoft, ils rendent cela très facile en transmettant les commentaires directement dans Github :
Compatibilité PostgreSQL avec Azure
Versionnement
Selon la documentation du produit, Single Server cible les versions de PostgreSQL dans la plage majeure n-2 :
En tant que solution conçue pour la performance, un serveur unique est recommandé pour les ensembles de données de 100 Go et plus grand. Les serveurs ont fourni des performances prévisibles :les instances de base de données sont fournies avec un nombre prédéfini de vCores et d'IOPS (en fonction de la taille du stockage provisionné).
Extensions
Il existe un bon nombre d'extensions prises en charge, dont certaines sont installées prêtes à l'emploi :
[email protected]:5432 postgres> select name, default_version, installed_version from pg_available_extensions where name !~ '^postgis' order by name;
name | default_version | installed_version
------------------------------+-----------------+-------------------
address_standardizer | 2.4.3 |
address_standardizer_data_us | 2.4.3 |
btree_gin | 1.2 |
btree_gist | 1.5 |
chkpass | 1.0 |
citext | 1.4 |
cube | 1.2 |
dblink | 1.2 |
dict_int | 1.0 |
earthdistance | 1.1 |
fuzzystrmatch | 1.1 |
hstore | 1.4 |
hypopg | 1.1.1 |
intarray | 1.2 |
isn | 1.1 |
ltree | 1.1 |
orafce | 3.7 |
pg_buffercache | 1.3 | 1.3
pg_partman | 2.6.3 |
pg_prewarm | 1.1 |
pg_qs | 1.1 |
pg_stat_statements | 1.6 | 1.6
pg_trgm | 1.3 |
pg_wait_sampling | 1.1 |
pgcrypto | 1.3 |
pgrouting | 2.5.2 |
pgrowlocks | 1.2 |
pgstattuple | 1.5 |
plpgsql | 1.0 | 1.0
plv8 | 2.1.0 |
postgres_fdw | 1.0 |
tablefunc | 1.0 |
timescaledb | 1.1.1 |
unaccent | 1.1 |
uuid-ossp | 1.1 |
(35 rows)Surveillance PostgreSQL sur Azure
La surveillance des serveurs repose sur un ensemble de métriques qui peuvent être soigneusement regroupées pour créer un tableau de bord personnalisé :
Ceux qui connaissent Graphviz ou Blockdiag apprécieront probablement la possibilité d'exporter le l'intégralité du tableau de bord dans un fichier JSON :
En outre, les métriques peuvent — et doivent — être liées aux alertes :
Les statistiques de requête peuvent être suivies au moyen de Query Store et visualisées avec Query Performance Aperçu. Pour cela, quelques paramètres spécifiques à Azure devront être activés :
[email protected]:5432 postgres> select * from pg_settings where name ~ 'pgms_wait_sampling.query_capture_mode|pg_qs.query_capture_mode';
-[ RECORD 1 ]---+------------------------------------------------------------------------------------------------------------------
name | pg_qs.query_capture_mode
setting | top
unit |
category | Customized Options
short_desc | Selects which statements are tracked by pg_qs. Need to reload the config to make change take effect.
extra_desc |
context | superuser
vartype | enum
source | configuration file
min_val |
max_val |
enumvals | {none,top,all}
boot_val | none
reset_val | top
sourcefile |
sourceline |
pending_restart | f
-[ RECORD 2 ]---+------------------------------------------------------------------------------------------------------------------
name | pgms_wait_sampling.query_capture_mode
setting | all
unit |
category | Customized Options
short_desc | Selects types of wait events are tracked by this extension. Need to reload the config to make change take effect.
extra_desc |
context | superuser
vartype | enum
source | configuration file
min_val |
max_val |
enumvals | {none,all}
boot_val | none
reset_val | all
sourcefile |
sourceline |
pending_restart | fAfin de visualiser les requêtes lentes et les attentes, nous passons au widget Query Performance :
Requêtes de longue durée
Statistiques d'attente
Journalisation PostgreSQL sur Azure
Les journaux PostgreSQL standard peuvent être téléchargés ou exportés vers Log Analytics pour une analyse plus avancée :
Performances et mise à l'échelle de PostgreSQL avec Azure
Bien que le nombre de vCores puisse être facilement augmenté ou diminué, cette action déclenchera un redémarrage du serveur :
Afin d'atteindre un temps d'arrêt nul, les applications doivent être capables de gérer avec élégance les erreurs transitoires .
Pour les requêtes de réglage, Azure fournit au DBA des recommandations de performances, en plus des extensions pg_statements et pg_buffercache préchargées :
Haute disponibilité et réplication sur Azure
La haute disponibilité du serveur de base de données est obtenue au moyen d'une réplication matérielle basée sur un nœud. Cela garantit qu'en cas de panne matérielle, un nouveau nœud peut être mis en place en quelques dizaines de secondes.
Azure fournit une passerelle redondante en tant que point de terminaison de connexion réseau pour tous les serveurs de base de données d'une région.
Sécurité PostgreSQL sur Azure
Par défaut, les règles de pare-feu refusent l'accès à l'instance PostgreSQL. Étant donné qu'un serveur de base de données Azure est l'équivalent d'un cluster de bases de données, les règles d'accès s'appliqueront à toutes les bases de données hébergées sur le serveur.
En plus des adresses IP, les règles de pare-feu peuvent faire référence à un réseau virtuel, une fonctionnalité disponible uniquement pour les niveaux Usage général et Mémoire optimisée.
Une chose que j'ai trouvée particulière dans l'interface Web du pare-feu — je ne pouvais pas naviguer loin de la page pendant l'enregistrement des modifications :
Les données au repos sont chiffrées à l'aide d'une clé gérée par le serveur et les utilisateurs du cloud ne peuvent pas désactiver le cryptage. Les données en transit sont également cryptées — SSL requis ne peut être modifié qu'après la création du serveur de base de données. Tout comme les données au repos, les sauvegardes sont cryptées et le cryptage ne peut pas être désactivé.
Advanced Threat Protection fournit des alertes et des recommandations sur un certain nombre de demandes d'accès à la base de données considérées comme un risque de sécurité. La fonctionnalité est actuellement en préversion. Pour démontrer, j'ai simulé une attaque par force brute de mot de passe :
~ $ while : ; do psql -U $(pwgen -s 20 1)@pg10 ; sleep 0.1 ; done
psql: FATAL: password authentication failed for user "AApT6z4xUzpynJwiNAYf"
psql: FATAL: password authentication failed for user "gaNeW8VSIflkdnNZSpNV"
psql: FATAL: password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"
psql: FATAL: password authentication failed for user "BVH2SC12m9js9vZHcuBd"
psql: FATAL: password authentication failed for user "um9kqUxPIxeQrzWQXr2v"
psql: FATAL: password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"
psql: FATAL: password authentication failed for user "5LsVrtBjcewd77Q4kaj1"
....Vérifiez les journaux PostgreSQL :
2019-08-19 07:13:50 UTC-5d5a4c2e.138-FATAL: password authentication failed
for user "AApT6z4xUzpynJwiNAYf"
2019-08-19 07:13:50 UTC-5d5a4c2e.138-DETAIL: Role "AApT6z4xUzpynJwiNAYf" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-LOG: connection received: host=173.180.222.170 port=27248 pid=316
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-FATAL: password authentication failed for user "gaNeW8VSIflkdnNZSpNV"
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-DETAIL: Role "gaNeW8VSIflkdnNZSpNV" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:52 UTC-5d5a4c30.140-LOG: connection received: host=173.180.222.170 port=58256 pid=320
2019-08-19 07:13:52 UTC-5d5a4c30.140-FATAL: password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"
2019-08-19 07:13:52 UTC-5d5a4c30.140-DETAIL: Role "SWZnY7wGTxdLTLcbqnUW" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:53 UTC-5d5a4c31.148-LOG: connection received: host=173.180.222.170 port=32984 pid=328
2019-08-19 07:13:53 UTC-5d5a4c31.148-FATAL: password authentication failed for user "BVH2SC12m9js9vZHcuBd"
2019-08-19 07:13:53 UTC-5d5a4c31.148-DETAIL: Role "BVH2SC12m9js9vZHcuBd" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:53 UTC-5d5a4c31.14c-LOG: connection received: host=173.180.222.170 port=43384 pid=332
2019-08-19 07:13:54 UTC-5d5a4c31.14c-FATAL: password authentication failed for user "um9kqUxPIxeQrzWQXr2v"
2019-08-19 07:13:54 UTC-5d5a4c31.14c-DETAIL: Role "um9kqUxPIxeQrzWQXr2v" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:54 UTC-5d5a4c32.150-LOG: connection received: host=173.180.222.170 port=27672 pid=336
2019-08-19 07:13:54 UTC-5d5a4c32.150-FATAL: password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"
2019-08-19 07:13:54 UTC-5d5a4c32.150-DETAIL: Role "8BGXyg3KHF3Eq3yHpik1" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:55 UTC-5d5a4c33.154-LOG: connection received: host=173.180.222.170 port=12712 pid=340
2019-08-19 07:13:55 UTC-5d5a4c33.154-FATAL: password authentication failed for user "5LsVrtBjcewd77Q4kaj1"
2019-08-19 07:13:55 UTC-5d5a4c33.154-DETAIL: Role "5LsVrtBjcewd77Q4kaj1" does not exist.L'alerte par e-mail est arrivée environ 30 minutes plus tard :
Afin de permettre un accès précis au serveur de base de données, Azure fournit RBAC, qui est une fonctionnalité de contrôle d'accès natif du cloud, juste un outil de plus dans l'arsenal du PostgreSQL Cloud DBA. C'est aussi proche que possible des règles d'accès pg_hba omniprésentes.
Sauvegarde et restauration PostgreSQL sur Azure
Indépendamment des niveaux de tarification, les sauvegardes sont conservées entre 7 et 35 jours. Le niveau de tarification influence également la capacité à restaurer les données.
La récupération ponctuelle est disponible via le portail Azure ou la CLI et selon la documentation aussi granulaire que jusqu'à cinq minutes. La fonctionnalité du portail est plutôt limitée - le widget de sélection de date affiche aveuglément les 7 derniers jours comme dates possibles à sélectionner, bien que j'aie créé le serveur aujourd'hui. De plus, aucune vérification n'est effectuée sur l'heure cible de récupération - je m'attendais à ce que la saisie d'une valeur en dehors de l'intervalle de récupération déclenche une erreur empêchant l'assistant de continuer :
Une fois le processus de restauration lancé, une erreur, supposément causée par le de la valeur de la plage, apparaîtra environ une minute plus tard :
… mais, malheureusement, le message d'erreur n'a pas été très utile :
Enfin, le stockage de sauvegarde est gratuit pour des périodes de conservation allant jusqu'à 7 jours. Cela pourrait s'avérer extrêmement pratique pour les environnements de développement.
Conseils et astuces
Limites
Familiarisez-vous avec les limites de serveur unique.
Connectivité
Toujours utiliser la chaîne de connexion pour que la connexion soit acheminée vers le bon serveur de base de données.
Réplication
Pour les scénarios de reprise après sinistre, localisez les répliques en lecture dans l'une des régions jumelées.
Rôles
Tout comme c'est le cas avec AWS et GCloud, il n'y a pas d'accès superutilisateur.
GUC
Les paramètres nécessitant un redémarrage du serveur ou un accès superutilisateur ne peuvent pas être configurés.
Mise à l'échelle
Pendant la mise à l'échelle automatique, les applications doivent réessayer jusqu'à ce que le nouveau nœud soit activé.
La quantité de mémoire et les IOPS ne peuvent pas être spécifiés :la mémoire est allouée en unités de Go par vCore, jusqu'à un maximum de 320 Go (32vCores x 10 Go), et les IOPS dépendent de la taille du stockage provisionné pour un maximum de 6000 IOPS. À l'heure actuelle, Azure propose une option de prévisualisation de stockage volumineux avec un maximum de 20 000 IOPS.
Les serveurs créés dans le niveau de base ne peuvent pas être mis à niveau vers un usage général ou une mémoire optimisée.
Stockage
Assurez-vous que la fonction de croissance automatique est activée :si la quantité de données dépasse l'espace de stockage provisionné, la base de données entrera en mode lecture seule.
Le stockage ne peut être augmenté qu'à la hausse. Tout comme avec tous les autres fournisseurs de cloud, l'allocation de stockage ne peut pas être réduite et je n'ai trouvé aucune explication. Compte tenu de l'état de l'équipement de pointe, les grands acteurs du cloud peuvent se permettre qu'il n'y ait aucune raison de ne pas fournir des fonctionnalités similaires à la relocalisation des données en ligne LVM. Le stockage est vraiment bon marché de nos jours, il n'y a vraiment aucune raison de penser à réduire jusqu'à la prochaine mise à jour majeure de la version.
Pare-feu
Dans certains cas, les mises à jour des règles de pare-feu peuvent prendre jusqu'à cinq minutes pour se propager.
Un serveur situé dans le même sous-réseau que les serveurs d'applications ne sera pas accessible tant que les règles de pare-feu appropriées ne seront pas en place.
Les règles de réseau virtuel n'autorisent pas l'accès entre régions et, par conséquent, dblink et postgres_fdw ne peuvent pas être utilisés pour se connecter à des bases de données en dehors du cloud Azure.
L'approche VNet/Subnet ne peut pas être appliquée aux applications Web car leurs connexions proviennent d'adresses IP publiques.
Les grands réseaux virtuels seront indisponibles tant que les points de terminaison de service seront activés.
Cryptage
Pour les applications nécessitant une validation de certificat de serveur, le fichier est disponible en téléchargement sur Digicert. Microsoft vous a facilité la tâche et vous ne devriez pas avoir à vous soucier du renouvellement avant 2025 :
~ $ openssl x509 -in BaltimoreCyberTrustRoot.crt.pem -noout -dates
notBefore=May 12 18:46:00 2000 GMT
notAfter=May 12 23:59:00 2025 GMTSystème de détection d'intrusion
La version préliminaire d'Advanced Threat Protection n'est pas disponible pour les instances de niveau De base.
Sauvegarde et restauration
Pour les applications qui ne peuvent pas se permettre un temps d'arrêt régional, envisagez de configurer le serveur avec un stockage de sauvegarde géo-redondant. Cette option ne peut être activée qu'au moment de la création du serveur de base de données.
L'exigence de reconfiguration des règles de pare-feu cloud après une opération PITR est particulièrement importante.
La suppression d'un serveur de base de données supprime toutes les sauvegardes.
Après la restauration, certaines tâches post-restauration devront être effectuées.
Les tables non journalisées sont recommandées pour les insertions en bloc afin d'améliorer les performances, cependant, elles ne sont pas répliquées.
Surveillance
Les métriques sont enregistrées toutes les minutes et stockées pendant 30 jours.
Journalisation
Query Store est une option globale, ce qui signifie qu'elle s'applique à toutes les bases de données. Les transactions en lecture seule et les requêtes de plus de 6 000 octets posent problème. Par défaut, les requêtes capturées sont conservées pendant 7 jours.
Performances
Les recommandations de Query Performance Insight sont actuellement limitées à la création et à la suppression d'index.
Désactiver pg_stat_staements lorsqu'il n'est pas nécessaire.
Remplacez uuid_generate_v4 par gen_random_uuid(). Ceci est conforme à la recommandation de la documentation officielle de PostgreSQL, voir Building uuid-ossp.
Haute disponibilité et réplication
Il y a une limite de cinq répliques en lecture. Les applications intensives en écriture doivent éviter d'utiliser des répliques en lecture car le mécanisme de réplication est asynchrone, ce qui introduit des retards que les applications doivent pouvoir tolérer. Les instances dupliquées en lecture peuvent se trouver dans une autre région.
La prise en charge de REPLICA ne peut être activée qu'après la création du serveur. La fonctionnalité nécessite un redémarrage du serveur :
Les réplicas en lecture n'héritent pas des règles de pare-feu du nœud maître :
Le basculement vers le réplica en lecture n'est pas automatique. Le mécanisme de basculement est basé sur les nœuds.
Il existe une longue liste de considérations qui doivent être examinées avant de configurer des répliques en lecture.
La création de répliques prend beaucoup de temps, même lorsque j'ai testé avec un ensemble de données relativement petit :
Vide Vide
Passez en revue les paramètres clés, car Azure Database pour PostgreSQL est livré avec des valeurs par défaut de vide en amont :
[email protected]:5432 postgres> select name,setting from pg_settings where name ~ '^autovacuum.*';
name | setting
-------------------------------------+-----------
autovacuum | on
autovacuum_analyze_scale_factor | 0.05
autovacuum_analyze_threshold | 50
autovacuum_freeze_max_age | 200000000
autovacuum_max_workers | 3
autovacuum_multixact_freeze_max_age | 400000000
autovacuum_naptime | 15
autovacuum_vacuum_cost_delay | 20
autovacuum_vacuum_cost_limit | -1
autovacuum_vacuum_scale_factor | 0.05
autovacuum_vacuum_threshold | 50
autovacuum_work_mem | -1
(12 rows)Mises à jour
Les mises à niveau majeures automatiques ne sont pas prises en charge. Comme mentionné précédemment, il s'agit d'une opportunité d'économies de coûts, en réduisant le stockage auto-développé.
Améliorations PostgreSQL Azure
Séries temporelles
TimescaleDB est disponible en tant qu'extension (ne faisant pas partie des modules PostgreSQL), cependant, il n'est qu'à quelques clics. Le seul inconvénient est l'ancienne version 1.1.1, alors que la version en amont est actuellement 1.4.1 (2019-08-01).
[email protected]:5432 postgres> CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
WARNING:
WELCOME TO
_____ _ _ ____________
|_ _(_) | | | _ \ ___ \
| | _ _ __ ___ ___ ___ ___ __ _| | ___| | | | |_/ /
| | | | _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \
| | | | | | | | | __/\__ \ (_| (_| | | __/ |/ /| |_/ /
|_| |_|_| |_| |_|\___||___/\___\__,_|_|\___|___/ \____/
Running version 1.1.1
For more information on TimescaleDB, please visit the following links:
1. Getting started: https://docs.timescale.com/getting-started
2. API reference documentation: https://docs.timescale.com/api
3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture
CREATE EXTENSION
[email protected]:5432 postgres> \dx timescaledb
List of installed extensions
Name | Version | Schema | Description
-------------+---------+--------+-------------------------------------------------------------------
timescaledb | 1.1.1 | public | Enables scalable inserts and complex queries for time-series data
(1 row)Journalisation
En plus des options de journalisation PostgreSQL, Azure Database pour PostgreSQL peut être configuré pour enregistrer des événements de diagnostic supplémentaires.
Pare-feu
Le portail Azure inclut une fonctionnalité pratique pour autoriser les connexions à partir des adresses IP connectées au portail :
J'ai noté la fonctionnalité car elle permet aux développeurs et aux administrateurs système de se laisser entrer, et cela se démarque comme une fonctionnalité qui n'est offerte ni par AWS, ni par GCloud.
Conclusion
Azure Database pour PostgreSQL Single Server offre des services de niveau entreprise, cependant, bon nombre de ces services sont encore en mode aperçu :Query Store, Performance Insight, Performance Recommendation, Advanced Threat Protection, Large Storage, Cross-region Lire les répliques.
Alors que la connaissance du système d'exploitation n'est plus requise pour administrer PostgreSQL dans le cloud Azure, le DBA est appelé à acquérir des compétences qui ne se limitent pas à la base de données elle-même — mise en réseau Azure (VNet), sécurité de connexion (pare-feu ), visionneuse de journaux et analyse avec KQL, Azure CLI pour des scripts pratiques, et la liste continue.
Enfin, pour ceux qui envisagent de migrer leurs charges de travail PostgreSQL vers Azure, un certain nombre de ressources sont disponibles ainsi qu'une liste de partenaires Azure, dont Credativ, l'un des principaux sponsors et contributeurs de PostgreSQL.
