Partager via

Atteindre la haute disponibilité et l’extensibilité - ARR et l’équilibreur de charge matérielle

  • Article

par Won Yoo

atteindre la haute disponibilité et la scalabilité :
Microsoft Application Request Routing (ARR) pour IIS 7.0 et versions ultérieures et l’équilibreur de charge matériel.

Microsoft Corporation F5
Auteur : Won Yoo Auteur : Ryan Korock
Date de publication : 13 novembre 2008

Abstract

Ce document fournit des conseils prescriptifs sur la façon dont le routage des requêtes d’application (ARR) peut être utilisé avec un équilibreur de charge matériel pour obtenir une haute disponibilité et une scalabilité. L’équilibreur de charge BIG-IP F5 est utilisé dans ce document pour illustrer la relation de travail entre ARR et hardware d’équilibrage de charge.

Vue d’ensemble

Microsoft Application Request Routing (ARR) pour IIS 7.0 et versions ultérieures est un module de routage basé sur proxy qui transfère les requêtes HTTP aux serveurs de contenu en fonction des en-têtes HTTP, des variables de serveur et des algorithmes d’équilibrage de charge. Un déploiement ARR classique est illustré dans le diagramme ci-dessous :

Diagram of a typical A R R deployment. A R R provides high availability and scalability for the content servers.

Bien que ARR offre une haute disponibilité et une scalabilité pour les serveurs de contenu, le déploiement global n’est pas hautement disponible ou évolutif, car :

  • ARR est le point de défaillance unique.
  • L’extensibilité des serveurs de contenu est limitée par la capacité maximale d’un serveur ARR.

Pour surmonter ces défis, les administrateurs peuvent envisager d’utiliser plusieurs serveurs ARR avec des hardwares d’équilibrage de charge, tels que F5 BIG-IP. ARR peut être déployé en mode actif/passif pour atteindre uniquement la haute disponibilité ou en mode actif/actif pour atteindre la haute disponibilité et la scalabilité. Ce livre blanc décrit comment ARR et F5 BIG-IP peuvent être déployés ensemble pour activer les scénarios ARR principaux tout en obtenant une haute disponibilité globale et une scalabilité.

Utilisation du routage des requêtes d’application et F5 BIG-IP

ARR est créé en tant que module sur IIS et est conçu pour prendre les décisions de routage au niveau de la couche 7 (application). Plus précisément, ARR s’appuie sur un autre module IIS, réécritured’URL, pour inspecter les en-têtes de requête HTTP entrants et les variables de serveur pour prendre les décisions de routage. Étant donné cette conception, les administrateurs peuvent écrire des règles d’acheminement intelligentes en fonction des informations au niveau de l’application, telles que :

  • Nom d’hôte (HTTP_HOST) : routez le trafic vers différents serveurs de contenu en fonction du nom d’hôte.
  • Ressource demandée (URL) : en fonction des extensions de fichier, déterminez si les ressources demandées sont destinées au contenu statique ou au contenu dynamique et routez les requêtes en conséquence.
  • Informations client (HTTP_USER_AGENT) : en fonction du type et de la version du navigateur, routez les requêtes vers les serveurs de contenu appropriés.
  • En-têtes personnalisés (définir en tant que cookie par applications) : routez le trafic en fonction des informations de cookie définies par les applications, telles que la préférence utilisateur ou l’identificateur d'utilisateur.

Voici quelques-uns des exemples ci-dessus. Pour obtenir la liste complète des en-têtes HTTP et des variables de serveur, reportez-vous à l’annexe A.

La fonctionnalité de couche 3 et de couche 4 de F5 de Big-IP complète la force d’ARR en matière de prise de décisions de routage basées sur la couche 7, telles que les en-têtes HTTP et les variables de serveur. En même temps, ARR ne fournit pas de fonctionnalités de déploiement à tolérance de panne pour elle-même et doit s’appuyer sur d’autres technologies et solutions complémentaires pour obtenir une haute disponibilité pour le niveau ARR, comme indiqué ci-dessous :

Diagram of F five Big dash I P layer three and four functionality. F five Big dash I P layer three and layer four compliment A R R strength in making routing decisions based on layer seven.

Scénario 1 : routage HTTP et équilibrage de charge

Le scénario d’équilibrage de charge et de routage basé sur HTTP active une architecture de déploiement à 3 niveaux qui implique :

  • Niveau 1 (Web) : fournit deux objectifs de traitement du contenu statique et du routage et de l’équilibrage de charge des requêtes dynamiques restantes sur les serveurs de niveau 2.
  • Niveau 2 (application) : traite le contenu dynamique qui s’appuie sur la logique métier.
  • Niveau 3 (données) : stocke les données.

Le diagramme suivant illustre le déploiement à 3 niveaux :

Diagram illustrating the three tier deployment. It shows a routing rule that differentiates the static content form the dynamic content.

Bien que l’exemple ci-dessus montre une règle d’acheminement qui différencie le contenu statique du contenu dynamique, un autre scénario courant consiste à différencier les requêtes de présentation des requêtes de service web.

Option 1 : actif/passif

En mode actif/passif, il existe généralement deux serveurs ARR dans lesquels un serveur traite les requêtes tandis que l’autre serveur est un serveur de basculement. Comme indiqué ci-dessus, bien que cette configuration atteigne une haute disponibilité en supprimant le point de défaillance unique, il ne s’agit pas d’une solution de scale-out, car la capacité d’agrégation des serveurs de contenu est limitée par la capacité maximale d’un serveur ARR.

Dans cette configuration, étant donné que deux serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. L’adresse F5 BIG-IP est configurée pour qu’elle route toutes les requêtes vers le serveur ARR actif et route uniquement les requêtes vers le serveur ARR passif si nécessaire.

À l’exception de la fonctionnalité d’affinité de nom d’hôte dans ARR, il n’existe aucune information d’état d’exécution qui doit être partagée entre les deux serveurs ARR. Par conséquent, pour ce scénario, aucune configuration spéciale n’est nécessaire sur les serveurs ARR ni sur le serveur F5 BIG-IP. Même si vous utilisez la fonctionnalité d’affinité du serveur dans ARR, les informations d’état affinité seront mises à la disposition du serveur passif via un cookie dans l’en-tête de requête lorsque F5 BIG-IP achemine les requêtes vers le serveur précédemment passif mais maintenant actif.

Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

  • Suivez les étapes décrites dans ce document pour configurer la configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

  • Suivez les étapes décrites dans ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

  • À un niveau élevé, le document ci-dessus décrit :

    • Comment rendre le contenu statique disponible sur le serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Configuration F5 BIG-IP

Dans ce scénario, vous allez créer un serveur virtuel qui équilibre la charge sur un pool de deux serveurs ARR (ou plus). La méthode d’équilibrage de charge que vous sélectionnez doit envoyer tout le trafic au serveur ARR principal jusqu’à ce qu’il ne devienne pas disponible. À ce stade, le LTM BIG-IP doit envoyer tout le trafic au serveur ARR secondaire.

Étape 1 : Configurer le pool de serveurs ARR.

  • Dans la section Trafic local, cliquez sur Pools. Cliquez ensuite sur le bouton Créer pour créer un pool.
  • Tout nom unique fonctionne pour le pool ; l’exemple utilise ARR_Pool.
  • Pour le moniteur d’intégrité, vous pouvez utiliser un moniteur HTTP personnalisé ou le moniteur HTTP par défaut.
  • Vous pouvez laisser la méthode d’équilibrage de charge définie sur Round Robin. Dans ce scénario, étant donné qu’il n’existe qu’un serveur ARR actif et passif, l’équilibrage de charge n’est pas utilisé.
  • Veillez à activer l’activation de groupe prioritaire. Cela configure BIG-IP pour envoyer le trafic vers le ou les serveurs avec la valeur de priorité la plus élevée. Lorsque ces serveurs ne sont pas disponibles, BIG-IP envoie le trafic au serveur ARR avec la valeur de priorité la plus élevée suivante.
  • Dans ce scénario, le serveur ARR à 10.0.0.1 a une valeur de priorité de 1, et 10.0.0.2 a une valeur de priorité de 2. Tout le trafic sera envoyé à 10.0.0.2 jusqu’à ce qu’il tombe en panne, puis le trafic sera envoyé à 10.0.0.1.

Screenshot of the Big dash I P web page. In the Health Monitors box under Active, h t t p is highlighted. In the New Members box, the A R R server priority value is ten dot zero dot zero dot one.

Étape 2 : Configurer le pool de serveurs ARR.

  • Dans la section Trafic local, cliquez sur Serveurs virtuels. Cliquez ensuite sur le bouton Créer pour créer un serveur virtuel.
  • Tout nom unique fonctionne pour le serveur virtuel ; l’exemple utilise ARR_VS.
  • Pour la destination, vous pouvez utiliser l’adresse IP vers laquelle les utilisateurs pointent leurs navigateurs. Dans cet exemple spécifique, nous utilisons 65.197.145.23. Pour le port de service, nous utilisons « 80 ».
  • Pour la section Type de serveur virtuel, vous avez plusieurs options. Étant donné que vous dépendez d’ARR pour acheminer, vous pouvez sélectionner le protocole HTTP de performances, qui est conçu pour obtenir les meilleures performances.
  • Pour le pool par défaut, sélectionnez le pool que vous avez créé à l’étape 1.

Screenshot of the F five Big I P page. In the Name box A R R underscore V S is written.

  • À ce stade, vous devez être en mesure de vous connecter à ce serveur virtuel, qui sera envoyé au serveur ARR approprié.

Option 2 : Actif/Actif

En mode Actif/Actif, vous pouvez avoir deux serveurs ARR ou plus. Cette configuration obtient à la fois une haute disponibilité et une scalabilité, contrairement au mode Actif/Passif, ce qui n’atteint que la haute disponibilité. Comme indiqué précédemment, étant donné que plusieurs serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. Le BIG-IP F5 est configuré pour équilibrer la charge des requêtes entrantes sur tous les serveurs ARR disponibles et intègres, ce qui transfère à leur tour les requêtes aux serveurs de contenu. Quelle que soit la fonctionnalité d’affinité de serveur utilisée sur le BIG-IP F5 ou non, aucune configuration spéciale n’est nécessaire sur les serveurs ARR. Tout d’abord, les serveurs ARR utilisent une configuration partagée afin qu’ils soient configurés de la même façon. Deuxièmement, étant donné que ARR utilise un cookie client pour stocker les informations d’affinité du serveur pour sa propre utilisation, ces informations sont disponibles par requête et sont donc disponibles sur les serveurs ARR. Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

La configuration ARR pour Active/Active est identique à celle d’Active/Passive. La principale différence est la configuration de F5.

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

  • Suivez les étapes décrites dans ce document pour configurer la configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

  • Suivez les étapes décrites dans ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

  • À un niveau élevé, le document ci-dessus décrit :

    • Comment rendre le contenu statique disponible sur le serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Configuration F5 BIG-IP

Dans ce scénario, tous les serveurs ARR disponibles sont considérés comme actifs et candidats au trafic à charge équilibrée. Utilisez le LTM BIG-IP pour déterminer l’intégrité et les performances du front-end ARR et diriger le trafic vers les meilleures performances.

Étape 1 : Configurer le pool de serveurs ARR.

  • Dans la section Trafic local, cliquez sur Pools. Cliquez ensuite sur le bouton Créer pour créer un pool.
  • Tout nom unique fonctionne pour le pool ; les exemples utilisent ARR_Pool. - Pour le moniteur d’intégrité, vous pouvez utiliser un moniteur HTTP personnalisé ou le moniteur HTTP par défaut. - Étant donné que vous avez plusieurs serveurs ARR auxquels distribuer le trafic, vous devez sélectionner une méthode d’équilibrage de charge qui convient le mieux à vos besoins. En supposant que tous les serveurs ARR ont des caractéristiques matérielles similaires, une méthode d’équilibrage de charge dynamique, telle que la plus rapide, observée ou prédictive, vous donnera une distribution basée sur les performances.

Screenshot of the F five Big I P web page. In the Load Balancing Method box, Fastest Application is chosen.

Étape 2 : Configurer le serveur virtuel.

  • Dans la section Trafic local, cliquez sur Serveurs virtuels. Cliquez ensuite sur le bouton Créer pour créer un serveur virtuel.
  • Tout nom unique fonctionne pour le serveur virtuel ; l’exemple utilise ARR_VS. - Pour la destination, vous pouvez utiliser l’adresse IP vers laquelle les utilisateurs pointent leurs navigateurs. Dans cet exemple spécifique, nous utilisons 65.197.145.23. Pour le port de service, nous utilisons « 80 ». - Pour la section Type de serveur virtuel, vous avez plusieurs options. Étant donné que vous dépendez d’ARR pour acheminer, vous pouvez sélectionner le protocole HTTP de performances, qui est conçu pour obtenir les meilleures performances. - Pour le pool par défaut, sélectionnez le pool que vous avez créé à l’étape 1.

Screenshot of the F five Big I P web page. In the Default Pool box, the pool created in Step one, the A R R pool, is selected.

Scénario 2 : Hébergement partagé à l’aide de l’affinité de nom d’hôte

Ce scénario utilise la fonctionnalité d’affinité de nom d’hôte dans ARR pour activer un déploiement d’hébergement partagé pour :

  • Réduire la gestion manuelle et la maintenance impliquées dans le déploiement d’hébergement partagé traditionnel.
  • Optimiser les ressources de serveur existantes tout en veillant à ce que toutes les ressources du serveur soient utilisées uniformément.
  • Effectuer facilement un scale-out de l’environnement.
  • Créer des opportunités d’affaires pour vendre une capacité supplémentaire.

Pour plus d’informations sur l’hébergement partagé et ARR, reportez-vous à ce document.

Le diagramme suivant illustre l’environnement d’hébergement partagé à l’aide d’ARR : Diagram of the shared hosting environment using A R R.

Option 1 : actif/passif

Comme indiqué précédemment, en mode actif/passif, il existe généralement deux serveurs ARR dans lesquels un serveur traite les requêtes tandis que l’autre serveur est un serveur de basculement. Bien que cette configuration atteigne une haute disponibilité en supprimant le point de défaillance unique, il ne s’agit pas d’une solution de scale-out, car la capacité d’agrégation des serveurs de contenu est limitée par la capacité maximale d’un serveur ARR.

Dans cette configuration, étant donné que deux serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. L’adresse F5 BIG-IP est configurée pour acheminer toutes les requêtes vers le serveur ARR actif et acheminer uniquement les requêtes vers le serveur ARR passif si nécessaire.

La fonctionnalité d’affinité de nom d’hôte dans ARR affine les requêtes adressées à un serveur particulier (ou un groupe de serveurs dans RC) en fonction du nom d’hôte. Les informations d’état d’exécution du mappage affiné entre les noms d’hôte et les serveurs de contenu sont stockées en mémoire dans une instance d’un serveur ARR. Dans la version 1 d’ARR, ARR tire parti du Cache externe Microsoft pour IIS pour partager et gérer cet état d’exécution entre plusieurs serveurs ARR. Vous trouverez plus d’informations sur ce scénario dans ce document.

Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

  • Suivez les étapes décrites dans ce document pour configurer la configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

  • Suivez les étapes décrites dans ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

  • À un niveau élevé, le document ci-dessus décrit :

    • Comment rendre le contenu statique disponible sur le serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Étape 3 : Activer et configurer le cache externe.

  • Suivez les étapes décrites dans ce document pour activer et configurer le cache externe à utiliser avec ARR.

Configuration F5 BIG-IP

Dans ce scénario, vous allez créer un serveur virtuel qui équilibre la charge sur un pool de deux serveurs ARR (ou plus). La méthode d’équilibrage de charge que vous sélectionnez doit envoyer tout le trafic au serveur ARR principal jusqu’à ce qu’il ne devienne pas disponible. À ce stade, le LTM BIG-IP doit envoyer tout le trafic au serveur ARR secondaire.

Étape 1 : Configurer le pool de serveurs ARR.

  • Dans la section Trafic local, cliquez sur Pools. Cliquez ensuite sur le bouton Créer pour créer un pool.
  • Tout nom unique fonctionne pour le pool ; l’exemple utilise ARR_Pool. - Pour le moniteur d’intégrité, vous pouvez utiliser un moniteur HTTP personnalisé ou le moniteur HTTP par défaut. - Vous pouvez laisser la méthode d’équilibrage de charge définie sur Round Robin. Dans ce scénario, étant donné qu’il n’existe qu’un serveur ARR actif et passif, l’équilibrage de charge n’est pas utilisé. - Veillez à activer l’activation de groupe prioritaire. Cela configure BIG-IP pour envoyer le trafic vers le ou les serveurs avec la valeur de priorité la plus élevée. Lorsque ces serveurs ne sont pas disponibles, BIG-IP envoie le trafic au serveur ARR avec la valeur de priorité la plus élevée suivante. - Dans ce scénario, le serveur ARR à 10.0.0.1 a une valeur de priorité de 1 et 10.0.0.2 a une valeur de priorité de 2. Tout le trafic sera envoyé à 10.0.0.2 jusqu’à ce qu’il tombe en panne, puis le trafic sera envoyé à 10.0.0.1.

Screenshot of the Big I P web site. In the name box is A R R underscore pool. In the Local Traffic pane, Pools is selected.

Étape 2 : Configurer le serveur virtuel.

  • Dans la section Trafic local, cliquez sur Serveurs virtuels. Cliquez ensuite sur le bouton Créer pour créer un serveur virtuel.
  • Tout nom unique fonctionne pour le serveur virtuel ; l’exemple utilise ARR_VS. - Pour la destination, vous pouvez utiliser l’adresse IP vers laquelle les utilisateurs pointent leurs navigateurs. Dans ce cas, nous utilisons . Pour le port de service, nous utilisons « 80 ». - Pour la section Type de serveur virtuel, vous avez plusieurs options. Étant donné que vous dépendez d’ARR pour acheminer, vous pouvez sélectionner le protocole HTTP de performances, qui est conçu pour obtenir les meilleures performances. - Pour le pool par défaut, sélectionnez le pool que vous avez créé à l’étape 1.

Screenshot of the F five web page. In the Default Pool box, A R R pool is selected. In the Local Traffic pane, Virtual Servers is selected.

  • À ce stade, vous devez être en mesure de vous connecter à ce serveur virtuel, qui sera envoyé au serveur ARR approprié.

Option 2 : Actif/Actif dans ARR

En mode Actif/Actif, vous pouvez avoir deux serveurs ARR ou plus. Cette configuration obtient à la fois une haute disponibilité et une scalabilité, contrairement au mode Actif/Passif, ce qui n’atteint que la haute disponibilité. Étant donné que plusieurs serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. Le BIG-IP F5 est configuré pour équilibrer la charge des requêtes entrantes sur tous les serveurs ARR disponibles et intègres, ce qui transfère à leur tour les requêtes aux serveurs de contenu.

Comme indiqué précédemment, les informations d’état d’exécution du mappage affiné entre les noms d’hôte et les serveurs de contenu sont stockées en mémoire dans une instance d’un serveur ARR. Pour partager ces informations entre plusieurs serveurs ARR, le Cache externe Microsoft pour IIS est utilisé. Pour plus d’informations sur le cache externe, reportez-vous à ce document.

Configuration ARR

La configuration ARR pour Active/Active est identique à celle d’Active/Passive. La principale différence est la configuration de F5.

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

  • Suivez les étapes décrites dans ce document pour configurer la configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

  • Suivez les étapes décrites dans ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

  • À un niveau élevé, le document ci-dessus décrit :

    • Comment rendre le contenu statique disponible sur le serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
    • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Étape 3 : Activer et configurer le cache externe.

  • Suivez les étapes décrites dans ce document pour activer et configurer le cache externe à utiliser avec ARR.

Configuration F5 BIG-IP

Dans ce scénario, tous les serveurs ARR disponibles sont considérés comme actifs et candidats au trafic à charge équilibrée. Utilisez le LTM BIG-IP pour déterminer l’intégrité et les performances du front-end ARR et diriger le trafic vers les meilleures performances.

Étape 1 : Configurer le pool de serveurs ARR.

  • Dans la section Trafic local, cliquez sur Pools. Cliquez ensuite sur le bouton Créer pour créer un pool.
  • Tout nom unique fonctionne pour le pool ; l’exemple utilise ARR_Pool. - Pour le moniteur d’intégrité, vous pouvez utiliser un moniteur HTTP personnalisé ou le moniteur HTTP par défaut. - Étant donné que vous avez plusieurs serveurs ARR auxquels distribuer le trafic, vous devez sélectionner une méthode d’équilibrage de charge qui convient le mieux à vos besoins. En supposant que tous les serveurs ARR ont des caractéristiques matérielles similaires, une méthode d’équilibrage de charge dynamique, telle que la plus rapide, observée ou prédictive, vous donnera une distribution basée sur les performances.

Screenshot of the F five web page. In the Local Traffic box, Pools is selected. In the Load Balancing Method box, Fastest application is selected.

Étape 2 : Configurer le serveur virtuel.

  • Dans la section Trafic local, cliquez sur Serveurs virtuels. Cliquez ensuite sur le bouton Créer pour créer un serveur virtuel.
  • Tout nom unique fonctionne pour le serveur virtuel ; l’exemple utilise ARR_VS. - Pour la destination, vous pouvez utiliser l’adresse IP vers laquelle les utilisateurs pointent leurs navigateurs. Dans ce cas, nous utilisons . Pour le port de service, nous utilisons « 80 ». - Pour la section Type de serveur virtuel, vous avez plusieurs options. Étant donné que vous dépendez d’ARR pour acheminer, vous pouvez sélectionner le protocole HTTP de performances, qui est conçu pour obtenir les meilleures performances. - Pour le pool par défaut, sélectionnez le pool que vous avez créé à l’étape 1.

Screenshot of the F five web page. In the Local Traffic box, Virtual Servers is selected. In the Default Pool box, A R R Pool is selected.

Résumé

Dans ce livre blanc, deux scénarios ARR principaux ont été examinés pour obtenir une haute disponibilité et une scalabilité en déployant plusieurs serveurs ARR et en utilisant F5 BIG-IP.

Annexe

Annexe A : Tous les en-têtes HTTP et variables serveur disponibles pour écrire des règles de décision de routage.

ALL_HTTP ALL_RAW APPL_MD_PATH
APPL_PHYSICAL_PATH CERT_COOKIE CERT_FLAGS
CERT_ISSUER CERT_KEYSIZE CERT_SECRETKEYSIZE
CERT_SERIALNUMBER CERT_SERVER_ISSUER CERT_SERVER_SUBJECT
CERT_SUBJECT CONTENT_LENGTH CONTENT_TYPE
DOCUMENT_ROOT GATEWAY_INTERFACE HTTP_ACCEPT
HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_CONNECTION
HTTP_CONTENT_LENGTH HTTP_HOST HTTP_IF_MODIFIED_SINCE
HTTP_IF_NONE_MATCH HTTP_REFERER HTTP_UA_CPU
HTTP_USER_AGENT HTTPS HTTPS_KEYSIZE
HTTPS_SECRETKEYSIZE HTTPS_SERVER_ISSUER HTTPS_SERVER_SUBJECT
INSTANCE_ID INSTANCE_META_PATH LOCAL_ADDR
PATH_INFO PATH_TRANSLATED QUERY_STRING
REMOTE_ADDR REMOTE_HOST REMOTE_PORT
REMOTE_USER REQUEST_FILENAME REQUEST_METHOD
REQUEST_URI SCRIPT_FILENAME SCRIPT_NAME
SERVER_ADDR SERVER_NAME SERVER_PORT
SERVER_PORT_SECURE SERVER_PROTOCOL SERVER_SOFTWARE
URL