2:34 a.m.
I've been scouring through the install notes and the architecture documents but
didn't find my answer. Is there a way to "cluster" or replicate the
userportal app or is it strictly a single instance? Any thoughts to the scale of a large
VDI system with 10,000 desktops and their VMs and how that impacts the ovirt-engine and
the user-portal app?
I figure it has been discussed, but using the word cluster in a google search of the wiki
results in a lot of hits, none of them that I saw that are to do with clustering the
server, just the virtual machine nodes.
Brian
10:29 a.m.
On 10/04/2012 01:34 AM, Brian Vetter wrote:
I've been scouring through the install notes and the architecture
documents but didn't find my answer. Is there a way to "cluster" or
replicate the userportal app or is it strictly a single instance? Any thoughts to the
scale of a large VDI system with 10,000 desktops and their VMs and how that impacts the
ovirt-engine and the user-portal app?
I figure it has been discussed, but using the word cluster in a google search of the wiki
results in a lot of hits, none of them that I saw that are to do with clustering the
server, just the virtual machine nodes.
it shouldn't be a huge issue to deploy the user portal on another
machine (although current rpm may require the engine).
juan - i don't remember if you already looked at this or not yet?
Brian - btw, the user portal is pretty lightweight - its mainly java
script going to the client, and polling lightly on status changes (which
changes if it is in focus on the client (faster polling) or not (slower
polling).
spice also doesn't go through the user portal today.
11:20 a.m.
On 10/04/2012 09:29 AM, Itamar Heim wrote:
On 10/04/2012 01:34 AM, Brian Vetter wrote:
> I've been scouring through the install notes and the architecture documents but
didn't find my answer. Is there a way to "cluster" or replicate the
userportal app or is it strictly a single instance? Any thoughts to the scale of a large
VDI system with 10,000 desktops and their VMs and how that impacts the ovirt-engine and
the user-portal app?
>
> I figure it has been discussed, but using the word cluster in a google search of the
wiki results in a lot of hits, none of them that I saw that are to do with clustering the
server, just the virtual machine nodes.
it shouldn't be a huge issue to deploy the user portal on another
machine (although current rpm may require the engine).
As of today the RPMs have inter-dependencies, so it is not possible to
deploy only the user portal. We could make the user portal RPM
independent of the rest. As it is just a JavaScript application it could
even be deployed as static content to many web servers. Those servers
would then need to act as proxies for the requests that the user portal
makes to the backend (due to the same origin limitations in GWT), that
is not complicated. However the scalability bottleneck won't be in the
JavaScript application, but in the backend that processes the requests
that it sends, and we don't have any simple way to replicate it at the
moment, that would require many important changes.
Same for webadmin.
Brian, I will try to prepare some instructions on how to deploy the user
portal to a different machine, but it will be a manual process.
juan - i don't remember if you already looked at this or not yet?
I didn't look at this deeply. It may be worth to try to support this
independent deployment of GUI applications for next release. It would
also simplify GUI installation in Fedora.
But the real scalability bottleneck will still be in the backend, and
suporting an active-active cluster requires major changes.
Brian - btw, the user portal is pretty lightweight - its mainly java
script going to the client, and polling lightly on status changes (which
changes if it is in focus on the client (faster polling) or not (slower
polling).
spice also doesn't go through the user portal today.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
1:17 p.m.
On 10/04/2012 10:20 AM, Juan Hernandez wrote:
On 10/04/2012 09:29 AM, Itamar Heim wrote:
> On 10/04/2012 01:34 AM, Brian Vetter wrote:
>> I've been scouring through the install notes and the architecture documents
but didn't find my answer. Is there a way to "cluster" or replicate the
userportal app or is it strictly a single instance? Any thoughts to the scale of a large
VDI system with 10,000 desktops and their VMs and how that impacts the ovirt-engine and
the user-portal app?
>>
>> I figure it has been discussed, but using the word cluster in a google search of
the wiki results in a lot of hits, none of them that I saw that are to do with clustering
the server, just the virtual machine nodes.
>
> it shouldn't be a huge issue to deploy the user portal on another
> machine (although current rpm may require the engine).
As of today the RPMs have inter-dependencies, so it is not possible to
deploy only the user portal. We could make the user portal RPM
independent of the rest. As it is just a JavaScript application it could
even be deployed as static content to many web servers. Those servers
would then need to act as proxies for the requests that the user portal
makes to the backend (due to the same origin limitations in GWT), that
is not complicated. However the scalability bottleneck won't be in the
JavaScript application, but in the backend that processes the requests
that it sends, and we don't have any simple way to replicate it at the
moment, that would require many important changes.
Same for webadmin.
Brian, I will try to prepare some instructions on how to deploy the user
portal to a different machine, but it will be a manual process.
> juan - i don't remember if you already looked at this or not yet?
I didn't look at this deeply. It may be worth to try to support this
independent deployment of GUI applications for next release. It would
also simplify GUI installation in Fedora.
But the real scalability bottleneck will still be in the backend, and
suporting an active-active cluster requires major changes.
> Brian - btw, the user portal is pretty lightweight - its mainly java
> script going to the client, and polling lightly on status changes (which
> changes if it is in focus on the client (faster polling) or not (slower
> polling).
>
> spice also doesn't go through the user portal today.
Brian, the simplest to use multiple web servers for the user portal is
to configure each of them so that they proxy requests to the server
where ovirt-engine is installed. But that won't really make things
scale, as all the work will be performed by the engine server. To scale
a bit it is better to at least let the web server deliver the user
portal application without disturbing the application server. In order
to do this you will need to do the following:
1. Configure the machine where ovirt-engine is installed so that the
application server will accept AJP requests in a network interface
accessible from the rest of web servers. You will need to edit the
/usr/share/ovirt-engine/service/engine-service.xml.in file and make sure
that the AJP connector looks like this:
<socket-binding name="ajp"
port="$getInteger('ENGINE_AJP_PORT')"
interface="public"/>
The important part here is interface="public", the rest may be different
in your version as this has changed recently. Make sure that you only
change the interface.
(Take into account that the AJP protocol has no security or encryption
support -that is why we bind it to localhost by default- so you should
make sure this machine is in a secure network, or use the firewall to
restrict access).
2. Copy the contents of the
/usr/share/ovirt-engine/engine.ear/userportal.war to the web server
where you want to deploy it. I tend to use a tarball for this:
# cd /usr/share/ovirt-engine/engine.ear/userportal.war
# tar cvf userportal.tar *
Then copy/transfer the userportal.tar file to the web servers where you
want to deploy the user portal.
3. For each web server where you want to deploy the user portal copy the
contents of userportal.tar to the web server documents directory (I
assume you are using /var/www/html):
# cd /var/www/html
# mkdir UserPortal
# tar xvf userportal.tar
4. In a normal installation the HTML page hosting the user portal is
generated dynamically, but if you deploy to a web server statically you
are going to need a static version. You can get this from the server
where the engine is installed:
# wget --no-check-certificate
https://ovirt-engine.example.com/UserPortal/org.ovirt.engine.ui.userporta...
This will create a UserPortal.html file that you should copy to the
directory
/var/www/html/UserPortal/org.ovirt.engine.ui.userportal.UserPortal.
5. Configure your web server so that it will proxy the requests that the
user portal makes to the backend. This can be done creating a
ovirt-userportal.conf file in /etc/httpd/conf.d with a content like this:
ProxyPass
/UserPortal/org.ovirt.engine.ui.userportal.UserPortal/GenericApiGWTService
ajp://ovirt-engine.example.com:8702/UserPortal/org.ovirt.engine.ui.userportal.UserPortal/GenericApiGWTService
Note that in the ajp://... part you should put the address of the server
where the engine is installed and the port number of the AJP connector.
6. Configure SSL in your web servers, as the user portal will always use
SSL to communicate with the web server. The certificates that you use
are up to you, no restriction.
With this done you should be able to connect to the UserPortal using the
following URLs:
https://web-1.example.com/UserPortal
https://web-2.example.com/UserPortal
...
https://web-n.example.com/UserPortal
The same can be done for webadmin.
Hope that this helps. Let me know if you find issues.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
4434
days inactive
4435
days old
3 comments
3 participants
participants (3)
-
Brian Vetter -
Itamar Heim -
Juan Hernandez