Cluster oder Load Balance

Company Blogs 2016/02/19 投稿者 Armin Cyrus Dahncke Staff

Hochverfügbarkeit erreichen, aber wie?

Das Ziel jedes IT-Verantwortlichen ist es die Systeme seines Unternehmens "hoch verfügbar" zu machen und das aus gutem Grund. Für Unternehmen ist es unerlässlich sicherzustellen, dass ihre Systeme immer online sind. Weltweit wird daran gearbeitet so nah wie möglich an das "Verfügbarkeits Nirvana" von 99,9999 Prozent zu gelangen. Load Balancing und Clustering sind Methoden, die Hochverfügbarkeit versprechen. Aber wie funktionieren beide Methoden eigentlich genau?

Um diese Frage zu beantworten, muss zunächst geklärt werden, was Hochverfügbarkeit überhaupt bedeutet. Hochverfügbarkeit bezeichnet die Fähigkeit eines Systems einen kontinuierlichen und uneingeschränkten Betrieb innerhalb eines spezifizierten Zeitraums gewährleisten zu können. Ziel ist ein hoch verfügbares System, welches Anwendereingaben akzeptiert und zu jederzeit erfolgreich auf diese reagiert.

Der größte Aufklärungsbedarf rund um das Thema Hochverfügbarkeit ergibt sich bei dem Verständnis zweier Komponenten ihrer Implementierung: Load Balancing und Clustering. Oftmals unterliegen Administratoren dem Irrglauben, dass es ausreicht ihrem System einen Load Balancer vorzuschalten, um dieses "hoch verfügbar" zu machen. 

Was ist Load Balancing?

Der Zweck eines Load Balancers besteht schlichtweg darin Nutzeranfragen zwischen verschiedenen Ressourcen (z.B. Servern) zu lenken. Oftmals sind Load Balancer so programmiert, dass sie die Ressourcenauslastung maximieren. Basierend auf komplexen Algorithmen lenken sie Benutzerfrequenzen zu der Ressource im System, die zu dem jeweiligen Zeitpunkt die geringste Auslastung hat. Load Balancing erlaubt es Administratoren innerhalb eines Systems eine Vielzahl an Instanzen aufzusetzen und den Traffic gleichmäßig unter ihnen zu verteilen, sodass es keinen "Single Point of Failure" geben kann. Wenn eine Instanz ausfällt, wird der Load Balancer den Traffic bis zur Wiederverfügbarkeit auf andere Instanzen umleiten.

Damit trägt Load Balancing zwar zu einer hohen Verfügbarkeit bei, kann diese aber nicht alleine gewährleisten. Load Balancing lenkt den Traffic zwischen verschiedenen Ressourcen, stellt dabei allerdings kein konsistentes Benutzererlebnis zwischen ihnen her. Grund hierfür ist, dass Load Balancing die Kommunikation zwischen den Ressourcen nicht beeinflusst und damit auch die Aufrechterhaltung einer User-Session mit dem Server nicht sicherstellen kann. Suchindizies oder System Caches können Inkonsistenzen zwischen verschiedenen Servern aufweisen und zum Ausfall von Ressourcen und damit zu unzuverlässigen Systemprozessen führen.

Abbildung A: Load Balancing Setup

Was ist Clustering?

Beim Clustering werden verschiedene Instanzen (auch Knoten genannt) miteinander vernetzt und damit zu einem großen singulären System zusammengefasst. Hierdurch ergibt sich für den Anwender ein einheitliches Nutzererlebnis über alle Knoten hinweg. Dieses wird durch die gemeinsame Bereitstellung von Informationen zwischen den Knoten erreicht. Caches, Datenbankinhalte und Suchindizes können zwischen den Knoten kommuniziert oder direkt an einem zentralen Ort gespeichert werden. So eliminiert auch das Clustering den "Single Point of Failure", da jeder Knoten Zugriff auf das System erlaubt.

Allerdings wird, ähnlich wie beim Load Balancing, auch das alleinige Clustern Ihres Systems nicht ausreichen, um dieses "hoch verfügbar" zu machen. Clustering ohne Load Balancer bedeutet für den Anwender, dass er von jedem Knoten explizit Zugang zum System erfragen muss. Das heißt, dass der Nutzer eine für jeden Knoten spezifische URL eingeben müsste, um Zugang zum System zu erhalten. Damit gäbe es keinen einfach wiedererkennbaren "Point of Entry" in Form einer einheitlichen URL. Weiterhin würde jeder Nutzer selbst entscheiden über welchen Knoten er auf das System zugreifen möchte. Hierdurch kann es zu einem Ungleichgewicht in der Auslastung der verschiedenen Knoten und damit zu Über- oder Unterbelastungen kommen. Das Resultat wären Performanceprobleme und im schlimmsten Fall sogar der Ausfall einzelner Knoten.

Abbildung B: Cluster Setup

Beide Methoden in Kombination

Der Einsatz von nur einer der beiden Methoden eignet sich demnach nur in Einzelfällen. Um Ihr System "hoch verfügbar" zu machen, werden Sie vielmehr beide Methoden anwenden müssen, da Load Balancing und Clustering sich gegenseitig ergänzen. Load Balancer eignen sich zur Optimierung Ihrer Ressourcenauslastung und lösen damit Probleme, die sich bei dem einseitigen Einsatz von Clustering ergeben. Cluster gewährleisten demgegenüber konsistente Daten zwischen den einzelnen Knoten eines Systems und sorgen damit für ein einheitliches Nutzererlebnis. Hierdurch lösen Sie einen der Hauptnachteile der alleinigen Nutzung von Load Balancern.

Schalten Sie einem Cluster einen Load Balancer vor, bewegt sich Ihr gesamtes System in Richtung Hochverfügbarkeit. Alle Benutzeranfragen werden an einen Ort mit einzigartiger URL gesendet, um dann von einem Load Balancer weitergeleitet zu werden. Der Load Balancer sendet jede Anfrage an den am wenigsten ausgelasteten Knoten und steigert damit die Performance und Effizienz Ihres Systems. Nimmt ein Nutzer eine Änderung an einem Knoten vor, aktualisiert sich diese über das gesamte System, da alle Knoten miteinander kommunizieren. Das bedeutet, dass jeder Benutzer zu jeder Zeit auf konsistente Daten zugreift. Würde ein Knoten während einer Sitzung ausfallen, könnte der Load Balancer die Nutzeranfragen direkt an den nächst verfügbaren Knoten weiterleiten, ohne dass es zum Abbruch der Sitzung kommt. Automatisch steigert sich die Verfügbarkeit des gesamten Systems.

Abbildung C: Load Balancing mit Cluster Setup

Mehr Flexibilität duch den Einsatz von Open Source Software

Es ist offensichtlich wie sich Load Balancing und Clustering gegenseitig ergänzen, um die Verfügbarkeit Ihrer Systeme zu steigern. Den eigentlichen Praxistest muss das Setup aber erst dann bestehen, wenn Sie versuchen es vor dem Hintergrund Ihrer individuellen Systemarchitektur zu implementieren. Für viele Applikationen ist für den Einsatz von Clustering oder Load Blancing der Erwerb einer herstellerspezifischen Software nötig. Diese Software muss meist kommerziell erworben und in die eigene Systemarchitektur übernommen werden. Damit ergeben sich nicht nur Kosten für den Erwerb, sondern darüber hinaus der zusätzliche Aufwand der Installation und Konfiguration.

Open Source Technologien räumen diesen Nachteil oftmals aus, da sie einer Reihe verschiedener offener Standards folgen. Diese Standards erlauben der entsprechenden Applikation die einfache Verbindung und Integration mit anderen Systemen, die konform mit dem jeweils eigenen Standard sind. Inbegriffen sind Standards wie SOAP und JSON für Web Services, HTML5 und CSS3 für Web Standards, WebDAV für webbasiertes Distributed Authoring und Versioning und weitere Software, die dem Ansatz des sogenannten "vendor-agnostic" folgt. Die Applikation erfordert damit auf keinem Level herstellerspezifische Software, da die genannten offenen Standards weitverbreitet sind. Vendor Agnostic, die bei Open Source Sofware in beinahe jede existierende Systemarchitektur passt, reduziert die Anschaffungskosten und vereinfacht die Optimierung der Verfügbarkeit Ihres Systems.

Kritiker von Open Source Software führen häufig an, dass die Kosten der Einführung in vielen Fällen die Vorteile der zuvor erwähnten Flexibilität überwiegen. Diese Kosten beinhalten den Verlust von Support und Updates sowie den Mangel an Verlässlichkeit im Vergleich zu proprietärer Software. Tatsächlich bieten viele Anbieter von Open Source Software heute aber Subskriptions-Modelle an, die verlässlichen Support und regelmäßige Software-Updates beinhalten.

Was noch wichtig ist

Um die Hochverfügbarkeit des eigenen Systems zu erreichen, müssen alle "Single Points of Failure" beseitigt werden. In obiger Abbildung sehen Sie zwischen den Nutzeranfragen und Applikationsservern einen einzelnen Load Balancer und weiterhin einen einzelnen Controller zwischen den Applikations- und Datenbankservern. Diese "Single Points of Failure" können die Verfügbarkeit Ihres Systems bei Beeinträchtigung gefährden. Stellen Sie sich vor der einzelne Load Balancer würde ausfallen und damit das ganze System für Benutzeranfragen unverfügbar machen. Weiterhin wäre vorstellbar, dass die oben abgebildete Hardware an einem einzigen Ort oder Rechenzentrum stände. Gäbe es in diesem Rechenzentrum einen Strom- oder Netzwerkausfall, würde dies ebenfalls zum Ausfall des gesamten Systems führen.
 
Das Ziel von Hochverfügbarkeit endet nicht mit dem Clustering oder Load Balancing Ihres Systems. Vielmehr muss Ihre gesamte Architektur bewertet und von allen "Single Points of Failure" befreit werden. 

 

Weiterführende Informationen

Im Liferay Developer Network erhalten Sie weiterführende Informationen zum Thema und erfahren, wie Sie die Liferay Plattform aus technischer Sicht auf hohe Verfügbarkeiten ausrichten und die Performance Ihrer Systeme optimieren können. Zum Liferay Developer Network.
 

Setting up Liferay Portal 6.1 EE as a SP

Company Blogs 2012/05/24 投稿者 Armin Cyrus Dahncke Staff

 

If you have followed the IdP setup you will find the setup steps very similar.
First we need to setup a keystore, we gonna use the java keytool to create a keystore we can easily use from command line.
It is cruzial to create the key with the name of the SP-entity we want to use in the portal-ext.properties. In this case we will use liferaysamlspdemo
To have the keystore in a directory we can adress from liferay properties we can for ease of use execute the command in the liferay data directory
 
 
keytool -genkey -keyalg RSA -alias liferaysamlspdemo -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
 
The command line output looks somewhat like
 
MacBook-Pro:data xxx$ keytool -genkey -keyalg RSA -alias liferaysamlspdemo -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
 
What is your first and last name?
  [Unknown]:  Liferay SAML SP Demo
What is the name of your organizational unit?
  [Unknown]:  Liferay SAML SP Demo
What is the name of your organization?
  [Unknown]:  Liferay SAML SP Demo
What is the name of your City or Locality?
  [Unknown]:  Liferay SAML SP Demo
What is the name of your State or Province?
  [Unknown]:  Liferay SAML SP Demo
What is the two-letter country code for this unit?
  [Unknown]:  XX
Is CN=Liferay SAML SP Demo, OU=Liferay SAML SP Demo, O=Liferay SAML SP Demo, L=Liferay SAML SP Demo, ST=Liferay SAML SP Demo, C=XX correct?
  [no]:  yes
 
Enter key password for <liferaysamlspdemo>
(RETURN if same as keystore password):  
Re-enter new password: 
 
 
We need to bootstrap the SAML plugin in the portal-ext.properties
 
##
## SAML
##
 
# Enable SAML Plugin
saml.enabled=true
 
# Set the role to sp on the Service Provider side
saml.role=sp
 
# Set the SAML entity id, it matches the alias we used to setup the keystore
saml.entity.id=liferaysamlspdemo
 
# The metadata location for Identity Provider
saml.metadata.paths=http://localhost:8080/c/portal/saml/metadata
 
We also need a refererence to the keystore we setup earlier, therefore we need to add the following to portal-ext.properties
 
#
# Keystore
#
 
# keystore type
saml.keystore.type=jks
 
# location of the keystore
saml.keystore.path=${liferay.home}/data/keystore.jks
 
# pwd for accessing the keystore
saml.keystore.password=liferay
 
# pwd for accessing the certificate of the entity in the keystore
saml.keystore.credential.password[liferaysamlspdemo]=liferay
 
Finally we need to configure the Service Provider itsself there we add the following to portal-ext.properties
 
#
# Service Provider
#
 
# Service Provider SAML entity id
saml.sp.default.idp.entity.id=liferaysamlidpdemo
 
# Set the SAML authentication mandatory
saml.sp.sign.authn.request=true
 
# disable signatures for the demo
saml.sp.assertion.signature.required=false
 
# timeout setting for IdP clock deviation in ms
saml.sp.clock.skew=3000
 
# Session keep alive url
saml.sp.session.keepalive.url=http://localhost:8080/c/portal/saml/idp/keepalive
 
# Service Provider user attribute mappings
saml.sp.user.attribute.mappings=screenName=screenName\nemailAddress=emailAddress\nfirstName=firstName\nlastName=lastName
 
 
After applying these settings we can deploy the SAML-portlet plugin. I deployed first to the IDP and then to the SP.
 
http://localhost:8080/c/portal/saml/sso?entityId=liferaysamlspdemo
 
This url will initiate the SAML IdP based login process check out if it works.
 
njoy
 
p.s. This is a demo showing of the SAML 2 connection between 2 liferay instances on separate tomcats. Where one tomcat is the IdP on port 8080 and the SP is on a different liferay portal tomcat port 7080. 
 

Setting up Liferay Portal 6.1 EE as an IdP

Company Blogs 2012/05/24 投稿者 Armin Cyrus Dahncke Staff

As a result of my recent Demo at our hungarian symposium in Budapest I want to show today how I used the SAML Portlet to setup a liferay portal instance as an Identity Provider talking SAML2.

My next blog will show the Service Provider part with the same portlet but different configuration and a second liferay bundle working on different ports locally.

In case you are interested in seeing how it works in conjunction with salesforce I can recommend the blog from Mika

Setup of a Liferay Identity Provider

For my installation I used a bundle and the SAML-Portlet from the customer portal.
 
First we need to setup a keystore, we gonna use the java keytool to create a keystore we can easily use from command line.
It is cruzial to create the key with the name of the IDP-entity we want to use in the portal-ext.properties. In this case we will use liferaysamlidpdemo
To have the keystore in a directory we can adress from liferay properties we can for ease of use execute the command in the liferay data directory
 
keytool -genkey -keyalg RSA -alias liferaysamlidpdemo -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
 

The output looks like the following

 
MacBook-Pro:data xxx$ keytool -genkey -keyalg RSA -alias liferaysamlidpdemo -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
 
What is your first and last name?
  [Unknown]:  Liferay SAML IdP Demo
What is the name of your organizational unit?
  [Unknown]:  Liferay SAML IdP Demo
What is the name of your organization?
  [Unknown]:  Liferay
What is the name of your City or Locality?
  [Unknown]:  wherever 
What is the name of your State or Province?
  [Unknown]:  wherever
What is the two-letter country code for this unit?
  [Unknown]:  XX
Is CN=Liferay SAML IdP Demo, OU=Liferay SAML IdP Demo, O=Liferay, L=wherever, ST=wherever, C=XX correct?
  [no]:  yes
 
Enter key password for <liferaysamlidpdemo>
(RETURN if same as keystore password):  
Re-enter new password: 
 
Next we need to bootstrap the SAML plugin in the portal-ext.properties
 
##
## SAML
##
 
# Enable SAML Plugin
saml.enabled=true
 
# Set the role to idp on the Identity Provider and to sp in the Service Provider
saml.role=idp
 
# Set the SAML entity id, it matches the alias we used to setup the keystore
saml.entity.id=liferaysamlidpdemo
 
# We do not need SSL for this example, for production you would use a regular ssl certificate
saml.require.ssl=false
 
We also need a refererence to the keystore we setup earlier, therefore we need to add the following to portal-ext.properties
 
#
# Keystore
#
 
# keystore type
saml.keystore.type=jks
 
# location of the keystore
saml.keystore.path=${liferay.home}/data/keystore.jks
 
# pwd for accessing the keystore
saml.keystore.password=liferay
 
# pwd for accessing the certificate of the entity in the keystore
saml.keystore.credential.password[liferaysamlidpdemo]=liferay
 

Next we need to enable the IDP part of the SAML-Plugin(still in portal-ext.properties)

 

#
# Identity Provider
#
 
# Enable the Identity Provider
saml.idp.enabled=true
 
# set the SAML authentication as required
saml.idp.authn.request.signature.required=true
 
# set the Identity Provider entitiy id
saml.idp.entity.id=liferaysamlidpdemo
 
We also need to register the Service Providers (Part 2) to the IdP, which can be done like that in portal-ext.properties
 
# The metadata locations for the known Service providers. In case of liferay
# we can point to the metadataservice of the plugin, in this case we already setup the SP,
# which is just another instance of liferay with the same plugin running in sp mode.
saml.metadata.paths=\
http://beta.test.com:9080/c/portal/saml/metadata
 
saml.idp.metadata.attributes.enabled[liferaysamlspdemo]=true
saml.idp.metadata.attribute.names[liferaysamlspdemo]=screenName,firstName,lastName,emailAddress,uuid
saml.idp.metadata.session.keepalive.url[liferaysamlspdemo]=http://beta.test.com:9080/c/portal/saml/sp/keepalive

Setup Debugging with Devstudio

Company Blogs 2011/11/28 投稿者 Armin Cyrus Dahncke Staff

This Blog will quickly explain how to setup debugging in a Liferay Devstudio(EE), which will be leading us through easy steps:

 

  • get devstudio from liferay customer portal (http://www.liferay.com/group/customer/downloads/dev-studio/1.4)
  • get the source code from liferay customer portal (http://www.liferay.com/group/customer/downloads/liferay-portal/6.0)
  • installation of devstudio
  • installation of liferay source code as a project in eclipse
  • start debugging

 

So let us start:

First we download the archives from the liferay customer portal:

  • Go to Liferay.com and login
  • select Customer Portal, Select your Liferay Portal Version and get the Devstudio or just use the latest form here http://www.liferay.com/group/customer/downloads/dev-studio/1.4
  • Make sure you download the correct version for your OS

DevstudioDownload

 

Next we want to download the source code:

  • Back on the Product Selection page we navigate to the liferay version we want to debug (6.0 SP2 with Devstudio 1.4, 6.0SP 1 with Devstudio 1.2)
  • From the Box we choose the Liferay Source Code

Liferay Source Download

 

Once we have the Devstudio we can run through the Wizard based Installation process, requiring us to deploy a valid license. 

For the easy setup we can choose our workspace to be in the folder where we installed the Devstudio into, which is on my end: /Volumes/data/Liferay Developer Studio 1.4.0

Note that I am using a Mac, so my Workspace will be

/Volumes/data/Liferay Developer Studio 1.4.0

The source code of the portal ends up here

/Volumes/data/Liferay Developer Studio 1.4.0/portal-trunk

can also be 

c:/workspaces//Liferay Developer Studio 1.4.0/portal-trunk

if you are using another OS

 

If you want to debug liferay services it is also advised to install a proper database, as explained here:

http://www.liferay.com/community/wiki/-/wiki/Main/Database+Configuration

Elsewhise you can proceed and liferay will use HSQL as a database.

Next Step is to setup the liferay source code as a project in Devstudio:

  • Go to the Menu: File/Import or right click in the Project Explorer/Import

Import the source code as a project

 

From General we choose Import Existing Project

 

Import existing project

Next we select the directory where we unzipped the source code into and click finish.

Select source folder

Ok we are ready to setup the debugger now, by clicking on the small bug in the Devstudio Toolbar and click on Debug Configurations.

 

Debug Configuration

Then in the next Dialoque we will configure the liferay project as a source folder for the liferay server 6.0 EE.

  • Double click on Liferay v6.0 EE (Tomcat 6)
  • Select the Source Tab from the right
  • Click the add button
  • Choose Java Project
  • Select portal-trunk
  • Click ok
  • Leave the Dialoque and save

Setup Debugger

 

If we have setup everything correctly we should be able to debug now, lets open a Java File and set a break point to prove we actually can:

  • Press Ctrl(Cmd) + Shift + R and open StartupAction.java (Package: com.liferay.portal.events)
  • Set a breakpoint in line 65(Double Click on the left where the dot is on the screenshot)Set a break point
  • Start the Server in debug mode (Click on the small bug in the next menu)
  • Start debugging
  • You can open the Debug Perspective right now or wait until Devstudio catches the Debug event and shows a dialoque which will lead you there
  • Debugging
  • The play button on the top will let the server proceed execution and the arrow buttons to the left will let you proceed step by step

Enjoy debugging Liferay EE

 

Monitor Liferay cache behaviour with JConsole

Company Blogs 2011/07/27 投稿者 Armin Cyrus Dahncke Staff

A crucial point for any project is the use of cache strategies, especially when you try to implement a project the first time on a new infrastructure. Therefore I will give some hints  how you can easily get confident with our ootb caching strategies.

So lets get started with my prerequisites.

You download any tomcat bundle of liferay, I used 606 our latest community edition of the portal with tomcat 6.

As JConsole needs to connect to tomcat you will need to give tomcat some extra configuration. I added the necessary opts to catalina.sh (on windows that would be catalina.bat) somewhere near line 257.

(I have my catalina.sh stored in 606workspace/bundles/tomcat-6.0.29/bin)

 

CATALINA_OPTS="$CATALINA_OPTS \

-Dcom.sun.management.jmxremote \

-Dcom.sun.management.jmxremote.port=12345 \

-Dcom.sun.management.jmxremote.ssl=false \

-Dcom.sun.management.jmxremote.authenticate=false"
 
CATALINA_OPTS="$CATALINA_OPTS \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=12345 \ -Dcom.sun.management.jmxremote.ssl=false \ -Dcom.sun.management.jmxremote.authenticate=false"

 

Now we need to tell liferay that we would like to evaluate the ehcache statistics. We need an entry in portal-ext.properties for that, as this costs a small portion of performance it is disable be default.

 

My portal-ext.properties file is stored in /606workspace/bundles/portal-ext.properties, where bundles is the directory which includes tomcat*/bin

 

 #
 # Set this to true to enable Ehcache statistics.
 #
ehcache.statistics.enabled=true

 

So much for the setup, we can start the portal now (exec startup.sh in a shell or double click startup.bat on windows in tomcat bin folder)

 

Once the Portal is started go forth an create some WebContent in Liferay CMS and put the article on any page.

On my end I just used

http://localhost:8080/web/guest/home

and placed a Web Content Display Portlet on the page which used one content I have created earlier.

Screenshot from my browser on http://localhost:8080/web/guest/home with a web content display portlet

 

So now we can start jconsole from shell or commandline by typing in

jconsole

hit enter and it starts rightaway, as long as you have a full jdk installed.

JConsole has a startup screen

JConsole StartupScreen

 

We will choose org.apache.catalina... to connect to tomcat and directly land on the overview page in jconsole. To look at the cache hits we navigate to MBeans and then on the left tree we will walk following path.

net.sf.ehcache/CacheStatistics/liferay-multi-vm

Then you will have a lot of classes inside this container, which represent the caches of different entities etc., as we want to monitor the statistics of rendered journal content, the following class is what you want to find:

com.liferay.portal.kernel.dao.orm.EntityCache.com.liferay.portlet.journal.model.impl.JournalArticleImpl

Once you have discovered the class unravel the details by clicking on it and select

Attributes

 

JConsole Explorer view with Journal selected

 

Now the cache statistics overview will show up and every time you refresh your browser on 

http://localhost:8080/web/guest/home

the statistics will change.

Jconsole monitor snippet looking at a rendered journal cache

 

Have fun exploring

該当件数: 5 件