Saturday, April 18, 2015

Buddha, Dharma and Sangha in the Light of Modern Psychology

Buddhism cherishes its Three Jewels, which are keys on the path to enlightenment. They are the Buddha (a particular sublte, centered experience of self), the Sangha (the spiritual community), and the Dharma (the spiritual path and practice together with its knowledge).

Modern Psychology pursues a tripartite model of attitude change, that is mediators that facilitate an internal, cognitive reconstruction (adaption): consistent or favourable evaluation of self, satisfactory relationships with other people, and informational accuracy (know-how). Attitude change is key to changes dealing with emotional facticism, or samsaric roots. Abstract concepts only appear real to us because the invoke the same emotions that are evoked by other phenomena that we have experienced and classified as real at an earlier point in time.

There is a striking similarity between the Buddha Jewel and a favourable evaluation of self. The Buddha Jewel, as an ideal, propagates a completely centered ideal of self that no longer display samsaric roots. There are two relevant samsaric roots: physical matter (i.e. body, biology), thus in Buddhist terms it is favorable to give up identification with the body (and any physical phenomena beyond). Secondly, mental constructs, that most commonly includes concepts of a soul. Being free from both one resides as observer, experiencer, or in terms of acceptance and commitment therapy: as self-as-context. This detached form of observation ensures constistent and favourable evaluations of self that are independent from external circumstances and perceptions.

There is another similarity between the Sangha Jewel and satisfactory relations to others. It is much more likely that people will experience satisfactory relations to people who are on the same path as themselves. As spiritual seekers on a Buddhist path obviously are a minority, positive experience is more likely to be found in a Sangha than in the open public. However, today, with a huge industry of spiritualism, hierarchical thinking has been widely reintroduced into Sanghas, deviating form the Buddhist ideal of sameness in nature of all individuals. These misconstructions of Sangha reintroduce concepts of competition to realms that are supposedly devoid thereof.

Thirdly, the Dharma Jewel and the informational accuracy seeking, the knowledge how a goal can be achieved in a non-contradictory canon, strongly relate to each other. Cognitive progress will only arise from internalization of concepts, each step building upon prior experience. Thus the next step will have to be within the vicinity of the before, in a zone of proximal development (Vygotsky) or a zone of influence (when seen from an external perspective). This strongly suggests consistent syllabi like Buddha's Dharma or modern scientific theories are facilitators in this progress.

Buddha's teachings in many ways appear to be more psychological than spiritual. If one reduces spiritual commerce and religious ritualism, Buddhism appears as a sophisticated, more than 2000 year-old psychological syllabus based on introspection whose findings are astonishingly often confirmed by modern scientific studies.

Thursday, April 16, 2015

Loadbalancing WebSphere-Servers with URI-sensitivity and sticky sessions: Apache vs. IBM Edge

Today, most users will probably use hardware-loadbalancers. However, the rising use of virtual server farms does make software-loadbalancing convenient.
     
Some sites disallow the use of hardware-loadbalancers in serverfarm-installations (once traffic passes the outter rim of the installations, it may not leave it again within the same request). Thus, more sophisticated balancing will have to be done within the serverfarm. Using a multitude of worker nodes, it is convenient to have the nodes as similar as possible. In an ideal world, workers are aware of their peers and pass traffic on to their neighbors that can handle them. However, COTS or custom built software may have that kind of sophisticated session handling. A software-balancer on each node that handles all incoming traffic can do this job even if the application can not.

There are two widespread possibilities to do software loadbalancing on AIX: the IBM Caching-Proxy/Edge-Component with Context-Based-Routing, and Apache Webserver. This article compares the two required configurations for Java applications running in WebSphere servers.

Prerequisites

Three jobs need to be implemented and properly coordinated to balance traffic content-aware and session-aware:
  1. A load-balancing component that distributes all non-aware traffic evenly across the nodes
  2. Session-stickiness so sessions maintain on a node once the session has been initiated
  3. Content-awareness that overrides the above so that requests that require particular nodes will be routed there independent from a current session (a new session on a different node will be required).
For Java applications, session-stickiness is best done via JSESSIONID. This is called a passive cookie configuration, because the application server sets the cookies, the load balancer just reads them. The advantage of this method is that you can react on whatever the application server does. If it deletes the cookie, you're back to a  round-robin situation. However, different JVMs use different ways of attaching the node to session cookies. Tomcat appends its node ID separated with a dot ("."). IBM WebSphere servers append their CloneIDs with a colon (":"), and if several WebSphere servers may handle the same request that path may even stack with additional colons as the session passes those nodes. We will not cover that scenario in this article.

In an active cookie configuration on the other hand, the load balancer sets its own cookies, no matter what the application server does. Thus clients usually stay sticky within a whole browser session, if no URI-dependent rerouting is done (or any other span of time you want the cookie to be valid). Conveniently, you can decide on the cookie and its values within the load balancer configuration.

Apache (2.4) Configuration

For apache httpd loadbalancer configuration with URI sensitivity and session stickiness one needs mod_proxy, mod_proxy_balancer and mod_rewrite. Using WebSphere server, you should prepare the CloneIDs of your server instances. This can be done in the WebSphere admin console:

Middleware servers --> <server name> --> Web container --> custom properties.

Add one custom property for each host. This example uses nodes appnode1, appnode2 and appnode3:


Name: HttpSessionCloneId
Value: appnode1
Comment: Second part of JSESSIONID: CloneId

Passive Cookie Configuration


Here is a sample proxy configuration in httpd.conf:

Listen 80
ServerName http://www.ourapp.com
UseCanonicalName=on

<Proxy balancer://mycluster>
    RewriteEngine On

    # Rewrite Requests
    #

    RewriteCond %{QUERY_STRING}        ^.*useNode=1.*$
    RewriteRule (.*) http://www1.ourapp.com%{REQUEST_URI} [P,L]

    RewriteCond %{QUERY_STRING}        ^.*useNode=2.*$
    RewriteRule (.*) http://www2.ourapp.com%{REQUEST_URI} [P,L]

    RewriteCond %{QUERY_STRING}        ^.*useNode=3.*$
    RewriteRule (.*) http://www3.ourapp.com:1234%{REQUEST_URI} [P,L]

    ProxySet stickysession=JSESSIONID stickysessionsep=:

    BalancerMember http://www1.ourapp.com       route=appnode1
    BalancerMember http://www2.ourapp.com       route=appnode2
    BalancerMember http://www3.ourapp.com:1234  route=appnode3
</Proxy>

<Location /balancer-manager>
    SetHandler balancer-manager
    Order deny,allow
    Allow from all # You may want to restrict this to your local subnet
</Location>

ProxyPass /balancer-manager !

ProxyPass /ourapp         balancer://mycluster:/ourapp
ProxyPassReverse /ourapp  balancer://mycluster/ourapp

Step 1: Sending URI requests directly to target hosts

In this example, rewrite rules will send all URIs containing tag/value useNode=1 in their query string to host http://www1.ourapp.com on port 80. Server 3 listens on port 1234 in this example just to make a difference. The RewriteRule option [P] (proxy request) already includes [L] (last request), so this L is redundant and just for the sake of illustration. No further rules are being processed. So any requests that contain the above pattern will never be balanced but proxied prematurely.

Step 2: Balancing the requests

By adding the BalancerMembers and with the ProxyPass statement below, apache httpd will send any requests that do not satisfy one of our RewriteConds through the balancer. It will do so in a round-robin fashion and based on the number of requests already sent, as no other arguments have been specified. There are more modes you may want to check out.

Step 3: Adding sticky sessions

By naming each BalancerMember with route=appnodeX the balancer can decide which route to take. How to make that decision is specified by the stickysession tag in the ProxySet command. Stickysession reacts on cookies. In this example BalancerMembers use cookie JSESSIONID. For use with WebSphere servers, specify stickysessionsep=:

Apache httpd will then only use the part behind a colon to obtain the route. This route is compared with the contents of the route argument in the BalancerMember statement. If the cookie contents after the separator match the value of the route argument, then this BalancerMember is selected. Otherwise the requests are routed via default distribution mechanism. So this configuration satisfies all three above prerequisites.

Setting a server name and using the canonical name can be handy, especially if a balancer is running behind a gateway server that might terminate HTTPS requests, authenticaiton host, maybe even another shared load balancer within a serverfarm setting, or all of the above.

Active Cookie Configuration


An active cookie configuration with WebSphere may look like this. In this case the CloneID does not need to be changed, as it is not used anywhere in this configuration.

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://mycluster>
    RewriteEngine On

    # Rewrite Requests
    #
    RewriteCond %{QUERY_STRING}        ^.*useNode=1.*$
    RewriteRule (.*) http://www1.ourapp.com%{REQUEST_URI} [P,L,CO=ROUTEID:.appnode2:;]

    RewriteCond %{QUERY_STRING}        ^.*useNode=2.*$
    RewriteRule (.*) http://www2.ourapp.com%{REQUEST_URI} [P,L,CO=ROUTEID:.appnode2:;]

    RewriteCond %{QUERY_STRING}        ^.*useNode=3.*$
    RewriteRule (.*) http://www3.ourapp.com:1234%{REQUEST_URI} [P,L,CO=ROUTEID:.appnode3:;]

    ProxySet stickysession=ROUTEID

    BalancerMember http://www1.ourapp.com       route=appnode1
    BalancerMember http://www2.ourapp.com       route=appnode2
    BalancerMember http://www3.ourapp.com:1234  route=appnode3
</Proxy>

<Location /balancer-manager>
    SetHandler balancer-manager
    Order deny,allow
    Allow from all # You may want to restrict this to your local subnet
</Location>

ProxyPass /balancer-manager !

ProxyPass /ourapp         balancer://mycluster:/ourapp
ProxyPassReverse /ourapp  balancer://mycluster/ourapp

In this example, we have to set cookies on our own. This is done (in Apache 2.4) with the "CO" option of the RewriteRule statement. Cookies will be valid for the duration of the browser session by default, unless you want to specify otherwise. Also, we deliberately add a leading "." just for the sake of demonstration (and to never obtain an empty ROUTEID cookie via the Header statement). Apache httpd will only use the part after the dot. The rest of the httpd configuration is equal to the passive configuration example. There is no need to set a stickysession-separator as a separator can be chosen deliberately, and apache httpd already uses a dot by default.

One more statment is needed in this configuration. When the server sends requests to BalancerMembers by default distribution rule, a cookie needs to be set. The server indicates this route selection by setting environment variable BALANCER_ROUTE_CHANGED. The actual route is written in BALANCER_WORKER_ROUTE. A Header add Set-Cookie statement is added to the server configuration to set that cookie. Subsequent requests will thus be sent to the same node as long as that cookie is not deleted (for example by evil users in their browser).


IBM Edge Configuration

The same configuration can be done with IBM Edge with content based routing (CBR). This example only provides a passive cookie configuration following the example above (the one the author really has seen in a  working live server configuration ...).

Again, you need to setup your CloneIds in WebSphere configuration as described above for appnode1, appnode2, and appnode3. Secondly, you need to setup a stub in ibmproxy.conf to tell the caching proxy, that hosts the cbr component, to proxy its requests.

proxy     /*    http://www.ourapp.com/*    www.ourapp.com


The actual rewriting is done in the configuration of the cbr component:

# Start executor
#
cbrcontrol set loglevel 5
cbrcontrol executor start
cbrcontrol executor set nfa 10.0.0.1

This sets loglevel to its highest setting, starts an executor, and sets the non-forwarding address of the server to 10.0.0.1. Set this to the interface your proxy runs on. You may want to do this if your first network interface is some admin LAN and you don't want to bind your proxy there.

# Add the cluster
#
cbrcontrol cluster add www.ourapp.com
cbrcontrol cluster set www.ourapp.com proportions 49 50 1 0

The names in this configuration must be real hostnames and addresses, they are not symbolic names. I recommend using the FQDN for your host you want your proxy to be reachable at. The cluster needs a port where your users can reach it. This port needs to be defined in your config next.

# Define a port for the cluster
#
cbrcontrol port add www.ourapp.com@80
cbrcontrol port set www.ourapp.com@80 stickytime 0

In a passive cookie configuration, the stickytime on cluster ports needs to be set to 0 by convention. If you set a stickytime on the cluster port, you will immediately enter a sticky round-robin setting, ignoring cookie configurations, which does not solve the above prerequisites. 

Next, worker bees need to be added. In this example, all worker bees are running on the same host, for example, when.distributing requests between several instances of a JVM that share the same host. You can define the worker bees in /etc/hosts with their IP address, if you don't want to add them to a DNS:

Sample /etc/host entry:
10.0.0.2   www1 www2 www3

Then, define the balanced nodes in your cbr configuration. This example assumes that the WebSphere servers are listening on ports 10000, 10001 and 10002:

# Define the balanced nodes
#
cbrcontrol server add www.ourapp.com@80@www1 address 10.0.0.2 mapport 10000 weight 9 cookievalue appnode1
cbrcontrol server add www.ourapp.com@80@www2 address 10.0.0.2 mapport 10001 weight 9 cookievalue appnode2
cbrcontrol server add www.ourapp.com@80@www2 address 10.0.0.2 mapport 10002 weight 9 cookievalue appnode3

This setting now should already do round robin distribution between the nodes (non-sticky). Now add rules for content based routing:

# Define rules on the cluster
#
cbrcontrol rule add www.ourapp.com@80@rule1 type content pattern "URI=*useNode=1*" priority 1
cbrcontrol rule add www.ourapp.com@80@rule2 type content pattern "URI=*useNode=2*" priority 2
cbrcontrol rule add www.ourapp.com@80@rule3 type content pattern "URI=*useNode=3*" priority 3

The syntax of attribute pattern is proprietary. Please consult IBM WebSphere documentation (see links below). You can basically match against http headers with <headername>=..., wildcard with asterisk (*), and do some Bracketing with (), & and |. As these commands are shell commands, quoting is essential. With these rules, all direct links are sent to their respective hosts once rules are bound to them. However, all URIs that do not match will still be distributed round robin. Therefore, a default rule needs to be added that is always true and implements session stickiness.

cbrcontrol rule add www.ourapp.com@80@rule4 type true priority 4 affinity passivecookie cookiename JSESSIONID

As apache httpd knows about the dot-separator that tomcat uses, IBM EDGE CBR components already know about the colon that WebSphere servers use.

# Map rules to the nodes
#
cbrcontrol rule useserver www.ourapp.com@80@rule1 appnode1
cbrcontrol rule useserver www.ourapp.com@80@rule2 appnode2
cbrcontrol rule useserver www.ourapp.com@80@rule3 appnode3
cbrcontrol rule useserver www.ourapp.com@80@rule4 appnode1+appnode2+appnode3

Next, it is advisable to start manager and advisor on your cluster for better balancing and to check for non-responding sites. However, advisors are optional.

# start manager and advisor
#
cbrcontrol manager start manager.log 10004
cbrcontrol advisor start http www.ourapp.com@80 advisor_80.log

Now you should be all set. You can check the fire ratios of your rules:

cbrcontrol rule report www.ourapp.com@80@rule1
cbrcontrol rule report www.ourapp.com@80@rule2
cbrcontrol rule report www.ourapp.com@80@rule3
cbrcontrol rule report www.ourapp.com@80@rule4

Some useful links and references:


Good luck!