vRealize Orchestrator 7.6 8.1 load balancer using haproxy

So far i tried f5 big ip ltm VE (failed due to limitations), kemp loadmaster VE(all ok – 1 month trial), and now i switched in my lab to haproxy.
All you have to do is a machine with haproxy + some ip interfaces on it, in my case i have 3 nodes for vro 8.1 and 3 nodes for 7.6, monitors/checks are set as per guide.
Bring your interfaces online and edit your haproxy.cfg to reflect your ips:
in my case 192.168.1.211 is the vip for vro 8.1 cluster
and 192.168.1.176 is the vip for vro 7.6 cluster

frontend vro
bind 192.168.1.211:443
mode tcp
default_backend vro81pool

backend vro81pool
mode tcp
balance leastconn
option httpchk GET /health
http-check expect status 200
server vro811 192.168.10.31:443 check port 8008
server vro812 192.168.10.32:443 check port 8008
server vro813 192.168.10.33:443 check port 8008

frontend vro768281
bind 192.168.1.176:8281
mode tcp
default_backend vro76pool8281

backend vro76pool8281
mode tcp
balance source
option httpchk GET /vco/api/healthstatus
http-check expect string RUNNING
server vro761 192.168.10.11:8281 check port 8281 check-ssl verify none
server vro762 192.168.10.12:8281 check port 8281 check-ssl verify none
server vro763 192.168.10.13:8281 check port 8281 check-ssl verify none

frontend vro768283
bind 192.168.1.176:8283
mode tcp
default_backend vro76pool8283

backend vro76pool8283
mode tcp
balance source
option httpchk GET /vco-controlcenter/docs/
http-check expect status 200
server vro761 192.168.10.11:8283 check port 8283 check-ssl verify none
server vro762 192.168.10.12:8283 check port 8283 check-ssl verify none
server vro763 192.168.10.13:8283 check port 8283 check-ssl verify none

vRealize Orchestrator 8.1 3 node cluster setup

vRealize orchestrator 8.1 3 node cluster setup

I have recoded a session from my destop while deploying 3 node vRealize orchestrator 8.1 cluster. I have no idea why the video editor moving some parts of the video  :/ It looks in 2-3 moments like it took some part of it, and put it to wrong part of timeline, no clue. I hope it’s not that much of confusion there so i just left it like that. In general you will understand the concept anyway. Next time i will see, maybe i will buy a proper video editor.

Ok i have done the video editing again in new software , still learning 😉 it has some green bottom layer, not sure why, but at least it ok with timeline.

One part that i missed in that recording was on how to enable the rest api  login with credentials ,  so in order to enable it , edit file:

/data/vco/usr/lib/vco/app-server/conf/vmo.properties on each node and add

in each node of your cluster and add at the end:

com.vmware.o11n.sso.basic-authentication.enabled = true

restart.

 

vRealize Orchestrator 8.1 is out and is still having issues with SNMP receiving traps

I have installed 8.1 vRealize Orchestrator cluster with 3 nodes . When you read the documentation and you will ask yourself a question do i really need 3 nodes instead of 2, then the answer is yes, you need 3 nodes to install it, that’s what i was told by VMware support, although the documentation uses word ‘recommended 3 nodes’. Anyway… so you replaced your certificates, cluster is installed, and you try to do snmp trap towards it, and it fails. The workflow that listens for trap on all devices is just waiting…

So again you have to do the trick with the snmp port (by default its the 4000 udp to your orchestrator unless you changed it).

As described here:

https://tsener.me/post/190159181895/vmware-vro-8-snmp-traps-howto-set-the-snmp-trap

you when you have 3 node cluster, you have to do this on 3 vro servers.

After this is completed, you have to go to your load balancer and add new rules for port 4000 udp as well.

aab1

without adding new service on port 4000 udp, the cluster would still not receive the trap. After this, your cluster will receive the snmp traps without a problem.

for this 4000 udp service, you can also put for monitor 8008 /health i suppose, i mean if vro is down then the snmp should be also not available.

1 other thing to mention, your certificate for vro8 cluster should be composed with CN of LB fqdn, not the leading node. I think i read it in some book that this owuld have to be CN of first node, but i was told by the VMware support today, that in CN i should put the cluster LB FQDN.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
countryName = NL
stateOrProvinceName = NoordHolland
localityName = Amsterdam
organizationName = HomeLabs
commonName = vrocluster81.greg.labs
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = vro811.greg.labs
IP.1 = 192.168.10.31
DNS.2 = vro812.greg.labs
IP.2 = 192.168.10.32
DNS.3 = vro813.greg.labs
IP.3 = 192.168.10.33
DNS.4 = vrocluster81.greg.labs
IP.4 = 192.168.1.211

 

vRealize orchestrator 7.6 cluster resuming work from failed vro node

I was wondering how the clustering works, i read the documentation and it was stated that the token will be resumed on another node. So i did a test, i make a small workflow that has to print out the node which is handling it, and it gets and sets a configuration element, so that i could see that it resumes and not restarts it.

Each scripting task is adding +1 , +2, +3 to the corresponding conf element inside vro. So that first element if it is 1 , it means it ran just once, if it was 2, it would mean that the workflow was restarted not resumed. on 1st script i add 1 , on 2nd i add 2, on third i add 3  to firstvar,secondvar,thirdvar configuration element variables.

I put sleep 90s between each scripting task. It started off from node 761.

aa1

After couple of seconds from start, i have powered off vro node 761. Another node took the execution from there:

aa2

Configuration element variables were initially set all to 0. After finishing the run they were set to 1,2,3:

aa3

Each script task had just to ouptut date/time + the host that ran it + get the content of configuration element variable + set it + get it again.

aa4

So to sum it up, yes, the orchestator nodes in cluster pick up the workflow job to resume in case their node on which they were running will be unavailable.

When i have powered on back the failed node vro761 (761,762,763 -> cluster7) suddenly the Logs section was put all together, and you can see how the it was handled:

aa5

 

vRealize Orchestrator 7.6 cluster deployment issues/not clear

Hello all,

i have tried to deploy vRO 7.6 in cluster mode,  since i don’t have much experience with it i just recorded my session hoping that somebody could point me out my mistakes. I have recorded a video while doing it. Any chance you can explain this behavior ?

What are the rules for it to work properly. Are we supposed to replace VAMI certificates ? Are we supposed to put cluster loadbalancer FQDN for the leader node hostname like in 8.0 ? Is it normal that java vro client can’t read messages from workflow tokens that were run on different nodes that the one to which it connects to (vro html5 client as well)? Is it expected behavior that once sync mode is applied then the html5 vro client is able to read log messages from all workflow tokens , does not matter if it was ran on that particular node or not.

One more question is that , according to the documentation when removing a node you have to just click delete on a replica node in VAMI, the node gets removed there, but when looking from control center it is still being ‘part of the cluster’ , so not sure what is going on, i have even rebooted the cluster, but its the same.

a2020-04-10 15_41_52-VMware vRealize Orchestrator Appliance