Environmint Configuration Scaleout

Scaleup

About

Scaleup is a function of Orchestration, which operates in conjunction with some functionalty of Runtime, to provide dynamically sized domains for 12c and simpler 11g assets. Note that it generates scaled up static configurations - however, support has been added into runtime in order to perform these tasks as a part of Online Updates, However, you can not shrink a domain once you have grown it, since we do not have a “this and only this” mode of operation as yet.

In its current form, it has some limitations, including but not limited to:

  • It is tested on multiple managed servers, but it will multiply them - so if you have osb_server1 and osb_server2, and you ask for 2 nodes, you will actually get 4 right now. (the idea being that if you have soa_server1 and osb_server1, they both get duped. This is tested).

  • It can operate on domains, instances, and system components, however it ONLY can update ports and listen addresses for domains, not instances/system components - you must use introspections for this (discussed below)

  • The configuration editing functionality is NOT foolproof, nor is it designed to be - it was mostly done as a convinience to myself since I was importing other peoples configurations. In particular, It is NOT smart enough to reliably understand any configuration edits but replacing managed server names and auto_X replacements

  • If you do not specify a host list, then it relies on your configuration defining either a server with a number as the last digit of the short, unprefixed name (server1-m is fine. serverA-m is not)

  • You can not yet specify a list of managed server names, and the ones in the base configurations MUST end with a number. Machine and NodeManager names WILL use replacements of hostnames and servernames if they exist, but otherwise they MUST end with a number as well. (If one does not exist, one will be added by the scaleout function rather than failing).

  • New certificates per host are NOT handled, however they ARE handled in the businessrules functionalty, which runs after scaleup - but you need to use BOTH if you want that. (If you have a shared certificate, such as a wildcard, a SAN, or a loadbalancer cert, this WILL be duplicated). See also the “mintpress_ssl” chef resource.

Transfers and Executes

These will only be scaled out if they have the property of “scaleout” set to “true”, otherwise they will be ignored!

Hosts and ports

The scaleup function will generate some variables for managed servers, instances, and system components which you can refernce:

nodeid - id of this machine serverid - id of this managed server or instance nodeonserver - id of this managed server/instance on this server

So in a 4 nodes accross 2 servers configuration, the values would be:

server serverid nodeid nodeonserver
soa1 1 1 1
soa2 2 1 2
soa3 3 2 1
soa4 4 2 2

This allows you to have a construct like:

“listenAddressPort”: “$(7002+$__.nodeonserver)”

To start all servers at port #7002, and increment them per node.

Usage

The most common way to call this is through the mintpress_project chef resource via the following parameters:

Parameter Function
scaleup_cluster_nodes Number of nodes to scaleup to. Default: 1.
scaleup_nodes_per_host Number of nodes to put on each host. Default: 1
scaleup_host_list A list of hosts to scaleup on to. This list is in order of node number
scaleup_node_filter A list of which nodes to build. This is so you can, for example, only build nodes 1,2 and 5,6 but not nodes 3,4 or 7,8. The reason you might do this is in the case of stretch clusters where only half the hosts are available, but you want to keep numbering consistent.
port_increment Whether to increment the listen ports of managed server for each host (i.e. 7002,7003,7004,etc rather than 7002,7002,7002). Default: false
seperate_admin Whether to seperate the admin server onto a seperate physical host, and move managed server #1 to node #2. Default: false

All of the parameters can optionally take a hash on asset, when passing in multiple assets, which looks like:

{
    "asset": 4,
    "biggerasset": 8,
    "*": 2
 }

Which will scale asset to 4 hosts, biggerasset to 8 hosts, and everything else to 2 hosts

Additionally, if you have multiple managed servers within a single configuration, you can scale those differently too by putting that within this hash - note that this MUST be put inside the asset structure when calling via mintpress_project, due to the way it unwraps

{
   "bigfmw": {
         "soa_server*": 8,
         "osb_server*": 2,
         "wsm_server*": 4
   }
}

If you wish, you can instead call the scaleup! function from the gem on your json file - do remember that you should call this before you call resolve_introspections!, since otherwise you will get weird results.

def scaleout!(jsondata, nodes, nodesperhost, port_increment, seperate_admin, host_list, dedicated_admin_node: false, node_filter: nil, system_components_per_host: 1, system_components: nil)

How it works

Notes:

  • "node id" can be either a numeric id, or an entry from scaleup_host_list, which will cause that hostname to be inserted into the appropriate places.

  • To generate this ID, hostnames will be split first on ".", then on "." or "-", then "-", then on "_", then "$" until a valid ID is found. This should cover the most common "postfix" (i.e. -mgt, -priv, etc) cases. One day I'd like a way to template this more generically, but I don't currently have a good answer as to the how. In particular, If you have hosts like:

    devhost1
    devhost1m
    devhost1b

    Then you must specify a host_list - host_list will correctly find the nodeid using a partial match from the list, but will NOT detect that devhost1m is node 1 without it! (The match logic is a substring match if using host_list, or the last digit being numeric if not).

  • The deduplication at the end will attempt to replace hostnames and servernames with runtime introspections, so that we end up with a reasonably clean/manageable configuration at the end of this process - for a normal configuration, there should be no more resourceList entries than we started with, with the exception of some JMSServer things, but StartupParameters and friends will be changed from, for example, /logs/osb_server1/osb_server1.log to /logs/%Name%/%Name%.log

Code:

  • for nodenumber in scaleup_cluster_nodes:

    • for managedServers

      • create new managed server (rename to managedServerName replacing the number with nodenumber)

      • update machine to point to a machine with node id nodenumber/scaleup_nodes_per_host

      • if portIncrement:

        • add nodenumber to listenPort,listenPortSSL

  • for all defined machines

    • if machine does not exist

      • create machine using template of existing machine, with node number updated to machine id

      • update nodemanager to point to nodemanager replaced with node number

  • for all defined nodemanagers

    • if nodemanager does not exist

      • create nodemanager using template of existing nodemanager, with node id of machine

      • <span style=“line-height: 1.42857;”>update listenAddress with node id of created machine</span>

      • update hostid with node id of created machine

  • for all defined hosts

    • if host does not exist

      • create host entry using template of existing host with node id of machine

      • update address of machine with node id of machine

  • for all configurationList itmes

    • if has targets AND target type is SERVER or it has the property ‘serverName’

      • for all newly created managed servers

        • if target contains the server we tempated off, duplicate resource

        • anywhere within the resource, if the string “_auto_X” is found, replace the ‘X’ with our server ID

        • anywhere within the resouce, if the name of the server we are templated off is found, replace it

        • if this does NOT make the name unique, add _auto_X to the name, replacing X with our server ID