Task #2705
closed
Create new VM for production Infrastructure Gateway (Liferay 6.2)
Added by Massimiliano Assante over 9 years ago. Updated about 9 years ago.
100%
Description
The Liferay 6.2 instance deployed on this VM will serve and host all the current D4Science production Gateways (i-marine, services, descramble and EGIP).
Although we are Evaluating and Studying a cluster architecture adoption for Liferay 6.2, this first version will be based on this single machine, so it has to be performing, in terms of RAM amount (8GB at least) and Disk speed and capacity (a separated /tmp folder of 100GB would do).
a proposed name could me infra-gateway.d4science.org (in a later moment i-marine.d4science.org, services etc will all point to it)
Updated by Andrea Dell'Amico over 9 years ago
Questions:
- Plans to deploy the application? Using the liferay bundle as in the past, or using the war(s) on an already configured tomcat instance? The second option as the advantage that tomcat can be upgraded when we need to fix security vulnerabilities
- Can we start from now with a separate reverse proxy, so that in future can put the web containers on private IPs as discussed some days ago?
- What about the database? The portals run with a local - old - postgresql instance. A separate postgresql server can avoid resource conflicts when there are lots of accesses. And with a pgpool installation, postgres can be easily replicated in a way completely transparent to the application. See https://support.d4science.org/issues/2227
Updated by Massimiliano Assante over 9 years ago
Andrea Dell'Amico wrote:
Questions:
- Plans to deploy the application? Using the liferay bundle as in the past, or using the war(s) on an already configured tomcat instance? The second option as the advantage that tomcat can be upgraded when we need to fix security vulnerabilities
Using (a customised) liferay bundle as in the past.
- Can we start from now with a separate reverse proxy, so that in future can put the web containers on private IPs as discussed some days ago?
Actually, there won't be web containers anymore. This new Liferay version supports virtual hosts, so i-marine.d4science.org and services.d4science.org (etc.) will be defined as virtual hosts in Liferay and they will be aliases to the same IP of infra-gateway.d4science.org (or whatever name we decide). The the idea is to move to sth like this https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/liferay-clustering (for which we have a ticket https://support.d4science.org/issues/2132)
- What about the database? The portals run with a local - old - postgresql instance. A separate postgresql server can avoid resource conflicts when there are lots of accesses. And with a pgpool installation, postgres can be easily replicated in a way completely transparent to the application. See https://support.d4science.org/issues/2227
The Database will be a Postgres 9.4 version, which in the first version can reside on the same infra-gateway.d4science.org machine.
Updated by Andrea Dell'Amico over 9 years ago
Massimiliano Assante wrote:
Using (a customised) liferay bundle as in the past.
OK
- Can we start from now with a separate reverse proxy, so that in future can put the web containers on private IPs as discussed some days ago?
Actually, there won't be web containers anymore. This new Liferay version supports virtual hosts, so i-marine.d4science.org and services.d4science.org (etc.) will be defined as virtual hosts in Liferay and they will be aliases to the same IP of infra-gateway.d4science.org (or whatever name we decide). The the idea is to move to sth like this https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/liferay-clustering (for which we have a ticket https://support.d4science.org/issues/2132)
You still need a web frontend, and we need a HA reverse proxy that terminates the SSL requests. I configured tomcat clusters in the past, mod_jk is not required and there are much better alternatives to apache for a load balancer. haproxy is the best, haproxy + varnish if we want an efficient caching layer.
- What about the database? The portals run with a local - old - postgresql instance. A separate postgresql server can avoid resource conflicts when there are lots of accesses. And with a pgpool installation, postgres can be easily replicated in a way completely transparent to the application. See https://support.d4science.org/issues/2227
The Database will be a Postgres 9.4 version, which in the first version can reside on the same infra-gateway.d4science.org machine.
I'd prefer to start with a separate VM from the beginning. The postgresql provisioning is automated, so there administration effort is the same.
Updated by Massimiliano Assante over 9 years ago
Andrea Dell'Amico wrote:
Massimiliano Assante wrote:
Using (a customised) liferay bundle as in the past.
OK
- Can we start from now with a separate reverse proxy, so that in future can put the web containers on private IPs as discussed some days ago?
Actually, there won't be web containers anymore. This new Liferay version supports virtual hosts, so i-marine.d4science.org and services.d4science.org (etc.) will be defined as virtual hosts in Liferay and they will be aliases to the same IP of infra-gateway.d4science.org (or whatever name we decide). The the idea is to move to sth like this https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/liferay-clustering (for which we have a ticket https://support.d4science.org/issues/2132)
You still need a web frontend, and we need a HA reverse proxy that terminates the SSL requests. I configured tomcat clusters in the past, mod_jk is not required and there are much better alternatives to apache for a load balancer. haproxy is the best, haproxy + varnish if we want an efficient caching layer.
Not sure what you mean by "You still need a web frontend", anyway for sure we need a reverse proxy that terminates the SSL requests. So far we used Apache2 installed on the same VM of the portal. In the vision of having a tomcat cluster we can definitely exploit whatever High Availability reverse proxy you think is best.
- What about the database? The portals run with a local - old - postgresql instance. A separate postgresql server can avoid resource conflicts when there are lots of accesses. And with a pgpool installation, postgres can be easily replicated in a way completely transparent to the application. See https://support.d4science.org/issues/2227
The Database will be a Postgres 9.4 version, which in the first version can reside on the same infra-gateway.d4science.org machine.
I'd prefer to start with a separate VM from the beginning. The postgresql provisioning is automated, so there administration effort is the same.
Fine let's use a a separate VM from the beginning for Postgres9.4
Updated by Tommaso Piccioli over 9 years ago
Let's start with two base machines:
infra-gateway.d4science.org Cores: 4, RAM: 5GB, disk: 16GB+100GB (/tmp)
db-gateway.d4science.org Cores: 2, RAM: 2GB, disk: 12GB
we will adapt the resources as soon as we collect the application's statistics.
Updated by Tommaso Piccioli over 9 years ago
- % Done changed from 0 to 20
All the Software is still to be installed.
Updated by Andrea Dell'Amico over 9 years ago
- Status changed from New to In Progress
- % Done changed from 20 to 80
On db-gateway.d4science.org postgresql 9.4 is running. There's a db defined named infra_liferay. The db username is infra, I'll communicate the password by other channels.
The database is accessible by infra-gateway.d4science.org and the Massi's desktop IP address.
infra-gateway.d4science.org: nginx is listening on port 80 and it redirects all the traffic to the local port 9090 (I see that's the port used by the liferay instances on the other portal servers). The latest release of Oracle JDK 7 in installed.
A liferay user can be used by Massi and Costantino to access the server.
I reported the same firewall rules used on the other portal servers. On those hosts there a result sets service that needs ports from 3000 to 3050 to be open. Port 52223 also needed to be open. I don't know if the same requirements still apply.
There's no startup script for the liferay service, I'll install it when the service will be in place.
Do you plan to have a caching server (eg. varnish) in front of liferay?
Updated by Massimiliano Assante over 9 years ago
thank you Andrea, we will start the service asap. I don't plan to have any caching server (eg. varnish) in front of liferay
Updated by Massimiliano Assante over 9 years ago
I don't have access to infra-gateway via ssh, not as root, nor as life user
nb-assante:~ massi$ ssh life@infra-gateway.d4science.org life@infra-gateway.d4science.org's password: nb-assante:~ massi$ ssh root@infra-gateway.d4science.org root@infra-gateway.d4science.org's password:
Updated by Andrea Dell'Amico over 9 years ago
Massimiliano Assante wrote:
I don't have access to infra-gateway via ssh, not as root, nor as life user
Sorry, I called the user liferay. Do you prefer life instead?
Updated by Massimiliano Assante over 9 years ago
- Assignee changed from _InfraScience Systems Engineer to Andrea Dell'Amico
Updated by Andrea Dell'Amico over 9 years ago
- Status changed from In Progress to Feedback
- % Done changed from 80 to 100
Are there any other requirements?
Updated by Massimiliano Assante over 9 years ago
- Status changed from Feedback to Closed
not at the moment, thanks.
Updated by Massimiliano Assante about 9 years ago
@andrea.dellamico@isti.cnr.it could you put the db password of the db named infra_liferay whose username is infra on /home/life of infra-gateway.d4science.org? (If you communicated me the password previously I lost it.)
Updated by Andrea Dell'Amico about 9 years ago
You can find it into the file /home/life/infra_db_pwd
