Les différentes licences K2

Lorsqu’on définit l’architecture de sa plateforme K2, on va déterminer le nombre de serveurs K2 dont on a besoin. Ensuite, il va falloir sélectionner le type de serveur parmi les types suivants :

  • serveur de développement,
  • serveur de production,
  • et serveur de non-production.

Dans un 1er temps, nous allons voir à quoi correspondent chacun de ces types et dans quel cas on peut les utiliser. Ensuite, nous verrons, en fonction de l’architecture cible souhaitée, combien de serveurs il faut utiliser.

Les différents environnements

On s’accordera sur le fait que la définition de ce qu’est un serveur de production ou un serveur de développement, est assez claire pour tout le monde , et ne mérite pas plus de détails. Il nous reste donc à traiter la définition de ce qu’est un serveur de non-production pour K2… hé bien, il s’agit simplement de tout serveur utilisé sur des environnements intermédiaires au développement et la production. On retrouvera derrière ce terme le classique serveur de recette/test, mais également (et éventuellement) les serveurs de qualification, de pré-production, d’intégration, de formation, de backup etc.

Chez K2, les serveurs de développement étant gracieusement offerts, il arrive régulièrement qu’on nous demande la différence entre un serveur de développement et un serveur de non-production. La question étant surtout “est-ce que je peux installer un serveur de développement sur mon environnement de recette ?”. Il faut savoir que non seulement il s’agit d’une infraction contractuelle , mais qu’il y a également des limitations techniques.

Les limitations techniques d’une licence de développement

Il y a plusieurs limites techniques fortes à l’utilisation d’une licence de développement :

  1. La licence est limitée à 10 utilisateurs (incluant le compte de service, et les comptes d’app pool s’ils sont différents du compte de service).
  2. Le serveur K2 doit être démarré en mode console (contrairement aux autres licences qui intègrent un mode service Windows). Ceci implique donc que pour que le serveur K2 tourne, il faut qu’une session utilisateur Windows soit active.
  3. Le tunning de le configuration n’est pas possible :
    1. un seul thread alloué et allouable,
    2. un seul CPU utilisé et utilisable.
  4. La seule topologie d’installation d’un tel serveur est la “single server”, c’est à dire que K2 ne peut pas être installé en mode ferme (il ne peut pas y avoir plusieurs serveurs K2 qui se répartissent la charge) et tous les composants serveur K2 doivent être installés sur le même serveur (pas de distribution possible du moteur de workflow, des smartforms et des sites web).

Combien de serveurs K2 utiliser ?

Vient ensuite la question du nombre de serveurs K2 à utiliser en fonction de l’architecture que l’on souhaite mettre en place. Dois-je utiliser autant de serveurs K2 que j’ai de serveurs virtuels dans ma ferme, ou est-ce basé sur les serveurs physiques, est-ce que les coeurs du processeur ont un impact ?

Le critère technique est le nombre de fois où le service Windows pour K2 va être déployé, et donc le nombre de K2HostServer nécessaires, le nombre de serveurs K2 sera donc lié au nombre d’instances de Windows (quelles soient physiques ou virtuelles et peu importe le nombre de coeurs) sur lesquelles le moteur K2 va être déployé. Sur un même environnement, plusieurs serveurs K2 seront nécessaires lorsqu’on décide de le redonder pour faire de la haute disponibilité. Si on distribue les composants sur des serveurs Windows différents (distribution des rôles K2), tant qu’il n’y a qu’un seul K2HostServer, il n’y a qu’un seul serveur K2 nécessaire.

Les éléments annexes comme les serveurs SQL, Exchange, SharePoint etc… ne rentrent pas en ligne de compte dans le calcul.

Prenons 3 exemples d’architecture possible et définissons le nombre de serveurs K2 nécessaire.

 NB : sur les schémas suivants, SQL server est à chaque fois représenté sous forme de cluster distant afin de montrer que l’architecture SQL server n’a pas d’impact sur le mode de licensing de K2. Mais ce type de déploiement n’est pas du tout obligatoire avec K2. Il est possible de se contenter d’une simple instance SQL, éventuellement mutualisée avec d’autres applicatifs… et même si ce n’est pas recommandé sur une production, le serveur SQL n’est pas obligatoirement distant du serveur K2.

Topologie "Single Server"
1 seul serveur avec tous les composants K2 : 1 seule licence
Topologie distribuée
1 serveur avec le composant K2 blackpearl, 1 autre avec le composant k2 smartforms : 1 seule licence
Topologie NLB
2 serveurs avec tous les composants K2 sur chacun : 2 licences

En espérant que ceci vous permette de mieux appréhender les termes “licence K2” et “serveur K2”.

Happy K2ing!

jean

Directeur technique de K2 France depuis 2006 et passionné par les technologies, je travaille dans le monde du BPM et des applications métier depuis... que je travaille :). Vous pouvez également me suivre sur twitter, linkedin.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.