Update xo-server.md

2015-11-10 14:12:20 +01:00
parent e4c08c7b9b
commit ef1b71d7d0
1 changed files with 76 additions and 0 deletions
--- a/xo-server.md
+++ b/xo-server.md
@@ -1,2 +1,78 @@
 # xo-server

+XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions. Let's see why.
+
+### Daemon mode
+
+As a daemon, XO-server is always up. In this way, it can listen and record every event occurring on your whole Xen infrastructure. Connections are always open and it can cache informations before serve it to another client (CLI, Web or anything else).
+
+### Central point
+
+Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server, and not all the Xen servers. With a traditional architecture:
+
+![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/without-xo.jpg)
+
+You can see how we avoid a lost of resources and bandwidth waste with a central point:
+
+![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/with-xo.jpg)
+
+### Events
+
+Legacy interfaces use the "pull" model, requesting data every "x" seconds:
+
+![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/noevent.jpg)
+
+It's **not scalable** and slow.
+
+With XO < 3.4, we used events in this way:
+
+![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/semievent.jpg)
+
+But interface was still lagging behind the server. With XO 3.4, we got a full event system, allowing instant display of what's happening on your infrastructure:
+
+![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/fullevent.jpg)
+
+### A proxy for your hosts
+
+XO-Server will act as a proxy for all your clients. It opens a lot of possibilities!
+
+#### Console proxy
+
+A good example is the console: you can now expose your consoles even if your clients are outside the network!
+
+![](https://xen-orchestra.com/blog/content/images/2015/03/console_before.png)
+
+![](https://xen-orchestra.com/blog/content/images/2015/03/console_after.png)
+
+#### VM streaming
+
+Another possibility is to stream a VM from a host to another.
+
+To do that previously, you needed to export your VM somewhere, then re-import it:
+
+![](https://xen-orchestra.com/blog/content/images/2015/10/oldsolution.png)
+
+Thanks to our architecture, it's now far better:
+
+![](https://xen-orchestra.com/blog/content/images/2015/10/newsolution.png)
+
+
+#### Auto patching
+
+### Pluggable
+
+It's really easy to plug other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
+
+#### ACLs
+
+![](https://xen-orchestra.com/blog/content/images/2014/Aug/ldap.jpg)
+
+![](https://xen-orchestra.com/blog/content/images/2014/Aug/permissions.jpg)
+
+### API
+
+An API is available to communicate directly with XO-Server. This part will be explained later.
+
+### NodeJS under the hood
+
+[NodeJS](https://en.wikipedia.org/wiki/Nodejs) is a software platform for scalable server-side and networking applications. It's famous for its efficiency, scalability and its asynchronous capabilities. Exactly what we need! Thus, XO-server is written in JavaScript.