OpenVMS Technical Update Days : Le serveur HTTPd WASD

Présentation au sujet: "OpenVMS Technical Update Days : Le serveur HTTPd WASD"— Transcription de la présentation:

1 OpenVMS Technical Update Days : Le serveur HTTPd WASD
Jean-François Piéronne SysGroup Remerciement à: Mark Daniel et Jean-Pierre Petit

2 Sommaire WASD versus CSWS (Apache) Caractéristiques
Architecture générale Performances Intégration dans OpenVMS

3 WASD/CSWS : Macro Comparaison
HTTP/1.1 Yes Alpha/Itanium Secure Sockets IPv4 & IPv6 Persistent Scripting Access Control Request ‘Rewrite’ Proxy Logging Perl, PHP, Python, etc. License GPL Apache and WASD both offer all the features expected in a modern Web package. Of course the implementation and detail may differ but each is highly competitive in offering a ‘full solution’. Request ‘rewrite’, an Apache description for being able to modify request handling and characteristics during processing, is paralleled in WASD’s conditional mapping and internal redirection facilities. WASD offers full proxy serving (HTTP, SSL, CONNECT), with on-disk caching, protocol tunneling and protocol gatewaying. Both WASD and Apache are available for free download and available for use under the GNU General Public License (GPL)

4 WASD/CSWS : Plateformes
Apache WASD Alpha Yes Itanium VAX No V6.0 V6.1 V6.2 V7.1 V7.2 V1.3 V7.3 V2.1 V8.2 V8.3 Install ODS-2 Install ODS-5 Mandatory V2.1 All of WASD features and facilities are available on all OpenVMS platforms for all OpenVMS versions from V6.0 onwards. The latest release of Apache tends to rely on recent tweaks and accommodations to underlying run-time libraries, TCP/IP packages and even (so I’m led to believe) kernel tweaks. This obviously lends some weight to WASD’s selection where sites cannot or will not update hardware or O/S versions for whatever reasons.

5 WASD/CSWS : Accès concurrents
Apache WASD Server Child Processes Single Process Concurrency Per-Process* VMS AST Multi-CPU Per-Process Multiple Instances** Scripting Per-Process or Subprocess Detached Process Apache, at least most of the current deployments, and certainly the OpenVMS release, uses a request-per-process model. A supervisory process creates child processes that are then managed through idle and request processing queues. Each child process handles a single request. Multiple child processes are used for request serving concurrency. This model is sometimes referred to as heavyweight-threading. Experimentation by the author has demonstrated something like a 10-15% overhead in OpenVMS Apache process requirements under load. This presumably is managing a process into and out-of the idle and processing queues, and associated overheads, within Apache. Hence to support 100 concurrent requests Apache would require something like 115 instantiated processes (even to serve static pages). WASD uses a single process and ASTs to enable an event-driven (mainly I/O but with some timer queue) multiple request concurrency. This model could be referred to as lightweight-threading. These are very lightweight in the sense they are VMS’ native threading model, almost negligible servicing cost and certainly containing none of the thread-management overhead of something like POSIX Threads or a process context. The WASD conservative approach to resource consumption in this respect is often a significant factor in preference over other approaches. * Pour supporter 100 requêtes concurrentes Apache nécessite un minimum ode101 processes. ** Multiple, per-CPU processes, synchronisation via mutex et DLM.

6 WASD/CSWS : Authentification
Apache WASD Package* Yes SYSUAF Module PKI** Custom*** WASD natively supports credentials from a significant number of sources: the SYSUAF with or without VMS rights identifier possession the ACME services plain-text lists WASD-specific binary authentication databases X.509 client certificate RFC1413 (Identification Protocol) authorization agent (user-written CGIplus-based authenticator) * package-specific username/password ** Public Key Infrastructure (X.509, etc.) *** User-written authentication support

7 WASD/CSWS : Scripting Apache WASD CGI Perl PHP Python Tomcat
Just* Yes Perl Module RTE** PHP RTE Python Tomcat Reverse Proxy Persistence WASD supports all the major dynamic content environments available to OpenVMS Apache. CGI performance under OpenVMS Apache is abysmal. There may be good reasons for this but a glance at the CGI performance data in later slides lends itself to ‘abysmal’ not being too wild a description. Both support ‘persistence’. This is a scripting characteristic rather than environment that lends itself to great efficiencies. See the following slides for more detail. * Implied criticism of OpenVMS Apache performance ** RTE is a persistent Run-Time Environment

8 Caractéristiques Implémentation complète HTTP/1.1
Support de services virtuels et de services multi-ports Messages paramétrables Support multi-langues Méthodes "GET", "HEAD", "POST“ et "PUT" Protection des transferts via la technologie “Secure Sockets Layer” (SSL) Support des cookies

9 Caractéristiques Service proxy, avec cache local, pour toutes les méthodes HTTP/1.0, plus la méthode CONNECT (permettant le “SSL tunnelling”) Reverse proxy HTTP, HTTPS Fonctionnalité "if-Modified-Since:" / "304 not Modified" (envoi du document seulement s’il a été modifié depuis une date spécifiée par le client) Support de la compression GZIP des requêtes et des réponses.

10 Caractéristiques Http/1.1 connexions persistantes (i.E. "Keep- Alive:“) Navigation dans les répertoires (générique et VMS- style) CGI scripting par sous-process ou par process détaché (configurable, automatique, choix du contenu MIME) Choix du compte exécutant le script dans le cas d’un process détaché (OpenVMS V6.2 minimum) "Keep-Alive:", reducing the number of TCP/IP connects required) Le choix du compte peut etre statique (fixer dans les regles) ou dynamique c’est le compte de login

11 Caractéristiques Passerelle HTTP:/HTTPS
Transforme une requête émise via standard HTTP en une requête SSL pour un service nécessitant un accès SSL Permettra également de sécuriser les scripts inter-serveur de manière transparente Conversion de caractères via les routines VMS NCS

12 Caractéristiques Scripts persistants
réduction du temps de latence, augmentation du “throughput” et diminution de l’impact sur le système) "CGIplus" scripting Interface Java, Python,… Run-Time Environments (RTEs) Le script n’est pas persistant, seulement l’environnement lui-même Par exemple pour Perl, Python… "ISAPI" extensions/scripting ISAPI : Microsoft

13 Caractéristiques CGI scripting via DECnet (avec réutilisation des connexions) Émulation OSU scripting, avec réutilisation des connexions, permettant l’utilisation de nombreux scripts OSU sans modifications Processeur de script (e.g. Perl, Python) configurable sur type du fichier (extension) Mécanisme de régulation du nombre de requêtes executées en parallèle (« throttling ») Scripts consommateurs de ressources Pics de charge réutilisation des connexions a partir de OSU 3.3a

14 Caractéristiques Pré-processeur HTML
Inclusion conditionnelle de documents Ajout de la date Etc.… Cache configurable,invalidation basée sur le temps pouvant être forcée Support image clickable (formats NCSA et CERN) Pré-processeur relativement sophistiqué OpenVMS 7.3 avec XFC devrait donner un boost significatif a ce type d’environement

15 Caractéristiques Règles de “mapping” puissantes et faciles d’emploi
Possibilité de règles conditionnelles Possibilité d’authentification par SYSUAF et droit d’accès d’un utilisateur par identifieur Utilisation de ACME ($ACM service) pour une intégration complète à l’authentification OpenVMS OpenVMS V7.3 minimum Alpha et Itanium uniquement "Basic" and "digest" user authentication and path/group-based authorization

16 Caractéristiques Configuration (méta-config)
Règles conditionnelles de « mapping » pour HTTPD$AUTH if (remote-addr: *) <map or authorize rule> else <etc> endif

17 Caractéristiques Trace des accès
Formats standard "common" et "combined" (ce qui permet l’analyse avec la plus part des outils d’analyse de trace) Format de traces personnalisable Création automatique, journalière, hebdomadaire ou mensuelle d’un nouveau fichier de traces La creation automatique maintient l’ordre des fichiers de traces

18 Caractéristiques Instances multiples
Inclus les fonctionnalités pour configurer, maintenir et coordonner plusieurs serveurs tournant sur un seul système ou sur un cluster Peuvent partager sur un nœud les requêtes entrantes Mécanisme de « round-roubin »

19 Caractéristiques Instances multiples (suite)
Le premier serveur s’exécutant créé automatiquement les autres instances Réalisé en utilisant le lock manager VMS Comporte des mécanismes d’équilibre de charge, de redémarrage et de « failover » automatiques La limitation devient rapidement la stack IP utilisée…

20 Caractéristiques Configuration on-line
Visualisation et modification de la configuration Graphique d’activité Rapports sur les requêtes Puissant outils de trace d’exécution d’une requête (WATCH)

21 Architecture générale
Un seul process Multi-threaded par asynchronisme Peux gérer plusieurs connexions simultanées Mécanisme interne de threading N’utilise pas Decthreads I/O asynchrone Utilisation intensive d’AST Support volume ODS5

22 Architecture générale
Configuration et monitoring via une interface WEB Authentification Interne (base HTA) Externe via UAF Validation par identifieur Utilisation possible de compte “nil-access” Externe via un agent Script CGIplus

23 Architecture générale
Droits d’accès Méthode de connexion (SSL ou non) Liste d’utilisateurs Identifieurs Base HTA

24 Configuration, exemple

25 Monitoring, exemple

26 Monitoring, exemple

27 Monitoring, exemple

28 Monitoring WATCH, exemple

29 Monitoring WATCH, exemple

30 Pré-processeur HTML Server Side Includes (SSI)
Ajout dynamique de d’informations à une page Création de page virtuelle Génération conditionnelle de page Exécution de commande DCL Exemples : <!--#exec cmd="show device/full tape1:" --> <!--#dcl show="device/full tape1:" --> <!--#dcl dir="web:[000000]“ par="/nohead/notrail" --> La directive #dcl exécute une commande DCL et incorpore le résultat dans le document. C’est une extension du serveur HTTPd WASD à la commande exec qui est également fourni. La directive #exec est uniquement pour les documents privilégiés, c’est-à-dire ceux appartenant au comte SYSTEM account, et non world-writeable.

31 Pré-processeur HTML <TITLE>Hello <!--#echo value="{REMOTE_HOST}!" --></TITLE> <H1>Simple SSI Demonstration</H1> Hello <!--#echo value={REMOTE_HOST} -->, the time here is <!--#echo value={DATE_LOCAL,12,5} --> <P> <UL> <LI><A HREF="ssi.txt">The source of this document</A> </UL>

32 Pré-processeur HTML <TITLE>Hello 192.168.0.30!</TITLE>
<H1>Simple SSI Demonstration</H1> Hello , the time here is 22:55 <P> <UL> <LI><A HREF="ssi.txt">The source of this document</A> </UL>

33 (wrapper* & persistent) Oui (wrapper* & persistent)
Scripting CGI Perl PHP Tomcat Python Persistence CSWS Oui (wrapper*) Module (persistent) OSU (wrapper* & persistent) Oui (wrapper* & persistent) Non WASD (native) * Un wrapper est une procédure DCL fournissant le support nécessaire.

34 Mécanisme de scripting
Trois types de process Sous-process Process detaché Peut ne pas appartenir au serveur Utilisation de $PERSONA (OpenVMS 6.2 minimum) Restriction des comptes autorisés par un identifier Decnet Réutilisation d’un process Peut être désactivé Performances…

35 Mécanisme de scripting
Environnements d’exécution Compte du serveur Mode par défaut Compte prédéfini Exemple : # one script to be executed under the account SET /cgi-bin/a_big_script* script=as=BIG_ACCOUNT # all scripts in this area to be executed under this account SET /database-bin/* script=as=DBACCNT

36 Mécanisme de scripting
Environnements d’exécution Compte utilisateur d’authentification (connexion) Exemple : SET /cgi-bin/cgi_process script=as=$ Environnement utilisateur de connexion SET /~*/www/cgi-bin/* script=as=~ UXEC /~*/cgi-bin/* /*/www/cgi-bin/* UXEC+ /~*/cgiplus-bin/* /*/www/cgi-bin/* USER /~*/* /*/www/* REDIRECT /~* /~*/ PASS /~*/* /dka0/users/*/* UXEC+ autorise les CGIPlus Le caractere ~ est substitue par le compte de login Essentials of setting up a user environment where access to a subdirectory in the user's home directory, [.WWW] with script's located in a subdirectory of that, [.

37 Mécanisme de scripting
Common Gateway Interface (CGI) Mode le plus simple Le script (programme) s’exécute et se termine Compatibilité Apache, OSU,… CGIplus, ISAPI Le script est rémanent Temps de latence très court Programmation (conception) plus complexe DECnet & OSU

38 Mécanisme de scripting
CGI Callouts Permet d’ établir un dialogue entre le script et le serveur Exemples : Modification de la durée de vie du process Conversion URL <-> nom de fichier Run-Time Environments Perl Java Raw TCP/IP Socket

39 Mécanisme de scripting
Exemple 1 $ say = "write sys$output" $! the next two lines make it CGI-compliant $ say "Content-Type: text/plain" $ say "" $! start of plain-text body $ show system

40 Mécanisme de scripting
Exemple 2 $ say = "write sys$output" $! the next two lines make it CGI-compliant $ say "Content-Type: text/html" $ say "" $! start of HTML script output $ say "<HTML>" $ say "Hello ''WWW_REMOTE_HOST'" !(CGI variable) $ say "<P>" $ say "System time on node ''f$getsyi("nodename")' is:" $ say "<H1>''f$cvtime()'</H1>" $ say "</HTML>"

41 Performances comparatives
Extrait de la documentation WASD AlphaServer /400 bi-processeur, VMS v7.3-2 et DEC TCP/IP 5.4. Keep-Alive désactivé: chaque requête nécessite une connexion/déconnexion TCP/IP complète. DNS et trace d’accès (logging) désactivés Le serveur et la machine tournant le test sont reliés par un réseau 100 Mbps FDDI WASD V9.0, CSWS V1.3 (Apache ) Configuration de base sans tuning particulier

42 Performance – 1 concurrent
Static 0kB: File comprising zero bytes of content. Included to measure the throughput of the entire network connection establishment, request acceptance, resources access, response delivery, connection dissolution – without the overhead of actually delivering any resource content. Static 64kB: File containing sixty-five kilobytes of content. Same measurement as above with the addition of multiple PDUs to the client. CGI: An executable that generates a CGI response header and variable quantities of response content (according to activation parameters). CGIplus: Same executable as CGI but persists between usages removing activation latencies. Included here for comparison with WASD CGI performance and shows approximately ten times greater throughput! Perl: Persistent interpreter under both platforms running the following script print "Content-Type: text/html\n\n <B>Hello!</B>"; PHP: Persistent interpreter under both platforms running the following script <? php echo "<B>Hello!</B>“ ?> More information: source:

43 Performance – 10 concurrent
The same performance results as described in the previous slide but this time with results from ten concurrent requests added for comparison. Obviously what works well under light load might behave differently and a heavier one. source:

44 Prochaines évolutions
Scripts « Inter-Serveur » Configuration et exécution de script (CGI/CGIplus) à travers un autre serveur tournant dans un même cluster en utilisant les routines ICC (Intra-Cluster Communications) Extension possible de ce mécanisme via TCP/IP à un serveur extra-cluster avec, dans ce cas, l’utilisation de SSL (par exemple au moyen d’une passerelle

45 Prochaines évolutions
Cache VLM Partagé entre les différentes instances du serveur Sélection automatique du document en fonction de la langue configurée dans le navigateur client Document générique EXAMPLE.HTML Français EXAMPLE_FR.HTML Allemand EXAMPLE_DE.HTML

46 Pour plus d’informations
WASD HTTPd OpenVMS Web Server discussion list : Alan Winston OpenVMS with Apache, OSU and WASD The Nonstop Webserver

47 Questions ?