More than 200 turn-key digital solutions are now available there, and they are accessible to everyone — both professionals and individuals — allowing them to meet all of their business needs. A company can digitalise its end-to-end activity, from website creation to billing and IT security, using only sovereign solutions hosted on a trusted cloud.

Byzaneo is a perfect example of what can be achieved with this ecosystem. Its co-founder, Baptiste Casnedi, explains how a partnership based on common values can be transformed into a concrete solution.

Byzaneo and OVHcloud

By Baptiste Casnedi

For 17 years now, Byzaneo has relied on OVHcloud infrastructures to host its solutions and its customers’ projects. This long-standing partnership was further strengthened last year with the arrival of a dedicated solution on the OVHcloud Marketplace, allowing any coding company of any size to benefit from Byzaneo’s DevOps expertise combined with the performance of our global infrastructure. 

OVHcloud has a long-standinginvolvement in innovation, and promotes alternative software solutions that reflect the values of an open and free world. Byzaneo shares identical values, and these are reflected in the h8lio solution: an open, alternative platform offering freedom. 

h8lio is an automated DevOps chain of 32 open-source tools and a managed Kubernetes solution that is set up for infrastructure as-a-service. It integrates resource management and subscription without commitment.This makes it the ultimate all-in-one platform to help IT teams develop, deploy, host and manage applications on a high-level cloud infrastructure. 

Innovation to reduce complexity and highlight performance 

Byzaneo’s priority is to deliver constant performance under all circumstances for the services our customers develop and deploy, while handling the significant increase in their demands. This way, we can fulfil our promise of scalability. To do this, in addition to the DevOps chain, we provide them with a managed, secure Kubernetes solution for deploying and managing their applications.  

The managed Kubernetes solution offered by h8lio is serverless, so that users do not have to manage their infrastructure. This means the infrastructure is transparent to users, but remains a key performance link: h8lio is based on OVHcloud’s bare-metal physical infrastructure.  

The only way to guarantee the quality and performance of a PaaS solution is with a robust, redundant infrastructure. 

Environmental responsibility at the heart of innovation 

While performance is undoubtedly a primary objective, energy efficiency is certainly another. The digital industry generates 3.7% of global CO2 emissions, according to The Shift Project. Like the legend of the hummingbird in the forest fire, we want to play our part in limiting the environmental impact of our solution. 

With the fine granularity (with vCPU and Giga) in real time offered by h8lio and integrated into the latest version, you can allocate and use the exact resources you need for your application or service to work properly. With both clear monitoring for billing and eco-responsibility, there are ecological and economic benefits. 

OVHcloud’s innovation also boosts energy performance, particularly the improvement of datacentre cooling and ventilation techniques. These include the design and deployment of proprietary water-cooling and air-cooling systems, which have eliminated the need for air conditioning in 98% of our server rooms.  

This environmental commitment is broader in scope, as OVHcloud is a signatory of the Climate Neutral Data Centre Pact, signed in 2021 and working to achieve carbon neutrality for datacentres by 2030. 

Made in Europe to address user concerns and match our values

The h8lio solution was developed in France, and relies on OVHcloud for a high-performance, sovereign hosting solution that strictly complies with European regulations (GDPR). 

Faced with the solutions offered by the Big Five (GAFAM) and other Chinese tech giants — along with the legislative framework that comes with them — the idea of a sovereign European cloud makes sense. This is why h8lio offers a French-based European alternative, hosted on OVHcloud datacentres that are located outside of Patriot Act zones. The 2 companies are also committed to GAIA-X, a project that sets out European ambitions in terms of cloud services. 

We promote a sovereign cloud that respects data privacy, and we work pragmatically with users as they transition to our cloud infrastructure. This way, whichever cloud provider you choose, you can migrate smoothly to a European cloud in several steps. This multi-cloud concept is a reality with h8lio. 

This cloud is based on our in-house expertise, combining our industrial disruptions with our ability to develop and automate alternative cloud solutions. We also rely on the innovations of our technological partners (often integrated as an advance preview), on our network of partners and on our Marketplace sellers who bring their own added value in terms of consulting, support, technological building blocks or packaged solutions. Finally, we use open-source communities to accelerate our developments and improve our products.

Thanks to Open Source, we can support our users as their needs evolve, providing them with cheaper and more flexible solutions. In addition to this support and contribution, we have become a member of the Open Invention Network (OIN), in an endeavour to do more to preserve and protect a movement whose values we have always shared.

Finally, and in more general terms, as Open Innovation is an integral part of our company culture, our Patent Pledge declaration is an even stronger promise of our commitment to freedom of development, as we allow communities to use the methods or protocols protected by our patents.

Open Innovation is at the heart of our industrial model

At OVHcloud, we are not afraid to think outside the box, to be inventive, to find our own path. In order to create value for our customers, we first need to create value for our business needs. We are constantly designing industrial solutions that are increasingly intelligent, frugal and eco-efficient so that we can integrate them into our datacentres.

We are continuously optimising our power distribution and cooling systems; water cooling, which we managed to industrialise very early on, is one of the most notable examples. As with most of our innovations, we transposed and adapted what was already working (in this case, using water’s heat transfer properties to cool desktop computers) in order to innovate and create our own datacentre-wide solutions.

Since 2001, as part of our Product Hacking initiative, we have also been designing our servers’ hardware architecture by selecting or developing components. Thanks to this Made in OVHcloud design, we can constantly optimise the performance of our Bare Metal Cloud (which supports the performance of our Hosted Private Cloud, Public Cloud and Web Cloud).

This combination of multiple innovations, both on our infrastructures and on our servers, also allows us to reduce our costs. It is thanks to this ongoing quest for the best price/performance ratio that we remain a leader in the European cloud market, and we are now identified as the leading European cloud provider in the global market in certain market segments (as shown in Forrester Wave 2020 and IDC Marketscape 2020).

For the first ten years of our activity, our main challenge was managing server density, so that we could increase our hosting capacity to meet the growing demand, despite only having a few datacentres in France. Back then, we used to keep our disruptions under the seal of industrial secrecy, to maintain our agility and efficiency.

In 2011, with our strong international expansion, we filed our first patents, primarily in the hardware sector. Then, from 2017, as our growth came with an increase in expertise, we began filing patents in more diversified areas. We wanted to assert our intellectual property to prevent other companies from preempting our industrial innovations and not claiming the rights. This strategy was clearly defensive, at a time when our innovations were being deployed in different datacentres around the world. We wanted to put in place a legal framework that was agile and protective enough for us to share our creations and enhance them with local industrial ecosystems wherever we set up new server clusters.

We then took this open, collaborative approach to an Open Hardware mindset when we joined the Open Compute Project in 2018, and since then, we have regularly shared our progress with OCP members.  We are convinced that this system of industrial innovation, based on collaboration and sharing, allows each party to do better and act faster. This pooling of knowledge aims for an open standardisation of datacentres, but more importantly, an overall improvement in their energy efficiency, which is closely linked to our strategic plan.

Open Source guarantees software independence

Our open cloud is also based on our software activity. Our solutions are always developed following market standards – with which our customers are often familiar, so that they can be users of it themselves – working closely with VMware, Veeam, Zerto and many other companies.

Aside from these standards, our solutions are mainly based on open source technology, which was our first step towards an open innovation approach. Being a historic part of this movement has been the cornerstone of our commitments to individual freedoms. We have always practised open, collaborative development, which allows our ecosystem to access the source code of the software solutions (or software components) that we regularly release on GitHub.

We are thus opening many of our own projects to the Open Source community. In the last few months we have released projects like The Bastion security infrastructure, the Kubernetes operator for Harbor or the Erlenmeyer and Catalyst tools for TSDBs.

We have also joined communities: The Linux Foundation (in 2018, with the launch of the Ceph Foundation), and the Cloud Native Computing Foundation (in 2019). As a result, our developments are never exposed to lobbying issues, but instead are guided by independent contributors or the board members of various foundations committed to Open Source.

Furthermore, we guarantee sovereignty for our users’ data across all of the technologies they use, whether they are using a market standard or open-source software.

Our active participation in Open Source communities guarantees our users transparency, reversibility and interoperability in our cloud solutions. Once again, our strategy is purely defensive, as it involves creating an open-source portfolio of software solutions  to protect us against potential attacks, while securing their freedom to be used by both us and the Open Source community.

In 2020, we wanted to go even further, and we joined the Open Invention Network (OIN). By joining this intellectual property fund of companies from around the world, we are pooling our Linux patents to protect this open-source operating system from legal action. By joining the OIN, we licence our patents, without fees, on the same footing as all other international members. By sharing all of our software patents, we are even more committed to defending open-source values and protecting a shared heritage.

Finally, as a founding member of Gaia-X, we want to foster innovation and collaboration to build an open European digital ecosystem and a data infrastructure based on openness, transparency and interoperability.

The Patent Pledge: the culmination of our commitment

But we do not want to stop there. In order to provide further assurance to Open Source contributors, we are making our technologies even more accessible by publicly sharing our patents under certain conditions. This Patent Pledge is a guarantee that we will not challenge any open-source software that may be linked to any of our existing or future software patents. It consolidates our patent-opening strategy in order to enrich the cloud market and strengthen our technological leadership, and, once again, it protects the open-source community. 

Building a transparent, reversible and interoperable cloud, and guaranteeing sovereignty for our users’ data, are the driving forces that make a difference for us. These are challenges that we take up every day, thanks to an ecosystem of partners, customers and communities that share our values of openness and collaboration. With them, we are building an alternative cloud that is fairer and more responsible, so that innovation can work for everyone. 

2015

As 2015 approached, our key objective was to design water blocks with an optimal performance of 120W and a water temperature of 30°C.

In order to simplify the process and reduce costs, we replaced the metal cover with an ABS plastic one.

Using plastic covers also allowed to build prototypes without metal fittings for the input and output pipes. Instead of fittings, the pipes were directly glued to the cover of the water block.

As with previous iterations, we also produced water blocks in smaller form factors. For instance, here you have a GPU water block:

3D printing water blocks

Using plastic covers for water blocks also opened the door to new prototyping process including 3D printing. We began to experiment with 3D printed ABS plastic water blocks, testing different types of covers.

3D printed cover variations:

CFD simulations

For the first time in OVHcloud’s history, we used advanced CFD (Computational Fluid Dynamics) simulations. This allowed us to optimise the thermal hydraulics of the copper-base plates, and further improve water block performance.

Redundancy

It was during this time that we first used four-tier covers, adding redundancy and improving reliability.

2017

We are always on the lookout for highly-standardised approaches which apply to different geographical zones’ and local customer needs. Alongside international expansion, we maintained an environmentally friendly approach, keeping ODP (Ozone Depleting Potential) and GWP (Global Warming Potential) levels very low across our datacentres.

By 2017 we were able to use water blocks with an optimal performance of 200W and a water temperature of 30°C and everything was fully-designed and manufactured internally at OVHcloud.

After the ABS plastic covers, it was time to test other plastics including polyamides.

Two examples of water blocks: one for standard CPUs, another for GPUs, with white polyamide covers:

A water block for high-density CPUs with a black polyamide plastic cover:

Experimenting with polyamide plastic also allowed us to quickly design and test different prototypes for enhanced CPU support and reduced cost.

2018-2019

At OVHcloud we have complete control from R&D to datacentre deployment. We can continuously innovate in short cycles which significantly reduces the amount of time between prototyping and large-scale deployment.

As a result, we are now more capable than ever of releasing new products to the market more quickly and for the best value. Many of our servers are delivered in 120 seconds with 100% service continuity, enhanced availability and optimised infrastructure performance.

Over the last two years we have begun to work with a new technology, using laser-welded metallic base-plates and covers. With this technology we can avoid screws and glue, and minimise the risk of leaks.

On these water blocks, piping is done entirely using copper-welded tubes.

As usual, we also build water blocks for specific form factors, like GPUs or high-density CPUs.

2020-…

At OVHcloud we continue to identify, transpose and adapt what works elsewhere to allow us to innovate and create our own solutions. We will follow disruption cycles in order to increase efficiency and reduce costs, always striving to create added value for our customers.

We are working on the next generation tier-4 water blocks, with our patented technology. Our tier-4 water blocks aren’t a prototype anymore, but prod-ready, and we are working extensively with simulations and tests to improve performance.

We are aiming for water blocks with a performance of 400W with a water temperature of 30°C, with a fully-redundant water supply.

And besides water blocks?

At OVHcloud we hare proud of our R&D laboratories. They are fully-committed to pushing our competitive advantages on hardware, software and our custom-proven methods of server stress validation and testing. In our labs, we design and test cooling solutions, new server prototypes and innovative storage options.

In future posts we will share other aspects of our industrial innovation process, and look at how our customers benefit from the continuous improvement of service reliability and the price efficiency it generates.

At OVHcloud, we love pragmatic solutions. In that spirit, some months ago, we started to offer GPUs in our Public Cloud, i.e. providing virtual machines with GPUs. But GPU virtualisation is not currently able to offer the level of performance we demand, so we chose to link the GPUs directly to the virtual machines, avoiding the virtualisation layer. KVM – our Public Cloud’s hypervisor – uses libvirt, which has a PCI passthrough feature that turned out to be exactly what we needed for this purpose.

NVMe architecture for our Public Cloud instances

In order to provide the best storage performance, we worked with a number of our customers on a PoC that used the same PCI Passthrough feature to incorporate the fastest storage device into our Public Cloud instances: NVMe cards with 1.8TB of space.

When it comes to storage and customer data, we have to be sure that when a customer deletes and releases an instance, we properly clean the device before allocating it to another instance. In this case, we patched OpenStack Nova in order to conduct a full erase of the device. In a nutshell, when an IOPS instance is released by a customer, it’s pushed to quarantine, where internal tools will run the required erase actions on the device. Once it’s done and checked, the device and the instance slot are pushed back in Nova as “available”.

You say fast, but how fast?

Let’s jump into some concrete examples and take the time to appreciate the awesome speed of these new instances! We’ll use the biggest instance model and run an I/O bench on a RAID 0. This way, we will see what the limits are when we aim for the fastest storage solution on a simple Public Cloud instance.

First, create an i1-180 instance, using the OpenStack CLI.

$ openstack server create --flavor i1-180 --image "Ubuntu 19.04" \
  --net Ext-Net --key-name mykey db01

Check the NVMe devices on the instance.

$ lsblk | grep nvme
nvme2n1 259:0    0  1.8T  0 disk
nvme1n1 259:1    0  1.8T  0 disk
nvme0n1 259:2    0  1.8T  0 disk
nvme3n1 259:3    0  1.8T  0 disk

We have our four NVMe devices, so let’s create a RAID 0 with them.

$ mdadm --create /dev/md1 --level 0 --raid-devices 4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started

Now we’ll format the raid device.

$ mkfs.xfs /dev/md1
meta-data=/dev/md1               isize=512    agcount=32, agsize=58601344 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=1875243008, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

After mounting the file system on /mnt, we are ready to run the test.

Read test

We’ll start with the read test, using 4k blocks, and as we have 32 vCores on this model, we’ll use 32 jobs. Let’s GO!

$ fio --bs=4k --direct=1 --rw=randread --randrepeat=0 \
  --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting \
  --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [r(32)][100.0%][r=9238MiB/s][r=2365k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3207: Fri Nov 29 16:00:13 2019
  read: IOPS=2374k, BW=9275MiB/s (9725MB/s)(1087GiB/120002msec)
    slat (usec): min=2, max=16031, avg= 7.39, stdev= 4.90
    clat (usec): min=27, max=16923, avg=419.32, stdev=123.28
     lat (usec): min=31, max=16929, avg=427.64, stdev=124.04
    clat percentiles (usec):
     |  1.00th=[  184],  5.00th=[  233], 10.00th=[  269], 20.00th=[  326],
     | 30.00th=[  363], 40.00th=[  388], 50.00th=[  412], 60.00th=[  437],
     | 70.00th=[  465], 80.00th=[  506], 90.00th=[  570], 95.00th=[  635],
     | 99.00th=[  775], 99.50th=[  832], 99.90th=[  971], 99.95th=[ 1037],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=144568, max=397648, per=3.12%, avg=296776.28, stdev=46580.32, samples=7660
   iops        : min=36142, max=99412, avg=74194.06, stdev=11645.08, samples=7660
  lat (usec)   : 50=0.01%, 100=0.02%, 250=7.41%, 500=71.69%, 750=19.59%
  lat (usec)   : 1000=1.22%
  lat (msec)   : 2=0.07%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=37.12%, sys=62.66%, ctx=207950, majf=0, minf=1300
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=284924843,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
   READ: bw=9275MiB/s (9725MB/s), 9275MiB/s-9275MiB/s (9725MB/s-9725MB/s), io=1087GiB (1167GB), run=120002-120002msec
 
Disk stats (read/write):
    md1: ios=284595182/7, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=71231210/1, aggrmerge=0/0, aggrticks=14348879/0, aggrin_queue=120, aggrutil=99.95%
  nvme0n1: ios=71231303/2, merge=0/0, ticks=14260383/0, in_queue=144, util=99.95%
  nvme3n1: ios=71231349/0, merge=0/0, ticks=14361428/0, in_queue=76, util=99.89%
  nvme2n1: ios=71231095/0, merge=0/0, ticks=14504766/0, in_queue=152, util=99.95%
  nvme1n1: ios=71231096/4, merge=0/1, ticks=14268942/0, in_queue=108, util=99.93%

2,370K IOPS. Those are awesome figures, aren’t they?

Write test

Ready for the write test?

$ fio --bs=4k --direct=1 --rw=randwrite --randrepeat=0 --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [w(32)][100.0%][w=6702MiB/s][w=1716k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3135: Fri Nov 29 15:55:10 2019
  write: IOPS=1710k, BW=6680MiB/s (7004MB/s)(783GiB/120003msec); 0 zone resets
    slat (usec): min=2, max=14920, avg= 6.88, stdev= 6.20
    clat (nsec): min=1152, max=18920k, avg=587644.99, stdev=735945.00
     lat (usec): min=14, max=18955, avg=595.46, stdev=736.00
    clat percentiles (usec):
     |  1.00th=[   21],  5.00th=[   33], 10.00th=[   46], 20.00th=[   74],
     | 30.00th=[  113], 40.00th=[  172], 50.00th=[  255], 60.00th=[  375],
     | 70.00th=[  644], 80.00th=[ 1139], 90.00th=[ 1663], 95.00th=[ 1991],
     | 99.00th=[ 3490], 99.50th=[ 3949], 99.90th=[ 4686], 99.95th=[ 5276],
     | 99.99th=[ 6521]
   bw (  KiB/s): min=97248, max=252248, per=3.12%, avg=213714.71, stdev=32395.61, samples=7680
   iops        : min=24312, max=63062, avg=53428.65, stdev=8098.90, samples=7680
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.86%, 50=11.08%
  lat (usec)   : 100=15.35%, 250=22.16%, 500=16.34%, 750=6.69%, 1000=5.03%
  lat (msec)   : 2=17.66%, 4=4.38%, 10=0.44%, 20=0.01%
  cpu          : usr=20.40%, sys=41.05%, ctx=113183267, majf=0, minf=463
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,205207842,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
  WRITE: bw=6680MiB/s (7004MB/s), 6680MiB/s-6680MiB/s (7004MB/s-7004MB/s), io=783GiB (841GB), run=120003-120003msec
 
Disk stats (read/write):
    md1: ios=0/204947351, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/51301962, aggrmerge=0/0, aggrticks=0/27227774, aggrin_queue=822252, aggrutil=100.00%
  nvme0n1: ios=0/51302106, merge=0/0, ticks=0/29636384, in_queue=865064, util=100.00%
  nvme3n1: ios=0/51301711, merge=0/0, ticks=0/25214532, in_queue=932708, util=100.00%
  nvme2n1: ios=0/51301636, merge=0/0, ticks=0/34347884, in_queue=1089896, util=100.00%
  nvme1n1: ios=0/51302396, merge=0/0, ticks=0/19712296, in_queue=401340, util=100.00%

1,710K IOPS on the write operation… Imagine what you could do with such a solution for your databases, or other highly-intensive, transactional use cases.

Of course, we’re presenting an optimal scenario for this example. RAID 0 is inherently risky, so any failure on one of the NVMe devices can corrupt your data. This means you absolutely must create backups for your critical data, but this in itself opens up a lot of new possibilities. So we’re 100% sure that your databases will love these instances! You can find more details about them on our Public Cloud website.

We manufacture our own servers, we build our own datacentres and we maintain strong, long-term relationships with other technological partners, with a clear objective: to deliver the most innovative solutions with the best price/performance ratio. The most obvious example, and one closely connected to our development, is the idea of using water to cool our servers.

We began to use water cooling at industrial scale in 2003, even though it went against the conventional wisdom at the time. This technology has allowed us to consistently increase servers’ performance while reducing energetic consumption in our data centers. The challenge was not only to find the right relation between pressure, flow rate, temperature and pipes diameter, but above all to manufacture the solution on a mass scale.

The environmental challenges associated with digital services are of vital concern too, especially for our datacentres. We are very aware of our own environmental impact and we constantly strive to reduce it on a daily basis. After power, cooling servers is usually the most costly activity, electricity-wise, for hosting providers.

Water cooling, combined with an outside air-cooling system, allows us to greatly optimise the Power Usage Effectiveness (PUE) of our datacentres. And less electric consumption means fewer costs for us and our customers, but also a reduced impact on the environment.

2003-2008

Since 2003, we have been developing our own water-cooling system and deploying it in our new datacentres. Our historic customers were the first to benefit from a groundbreaking and highly-effective process on an industrial scale.

Our first generations of water-block technology, were designed by our teams, and manufactured externally. These water blocks had an optimal performance of 60W at 30°C water temperature.

The first generation of water cooling used very simple water blocks, with two copper convex ends crimped together:

On the next iteration of our water blocks, we added some changes to improve reliability and reduce costs:

• The crimping technology is replaced by brazing
• Stainless steel push-in fittings replaced the brass-plated ones
• A cross is also added to the cover to better fix the water block onto the chip

In order to facilitate pipe fitting and improve sealing, we again changed the water block technology by introducing compression fittings, which are more reliable and easier to connect.

A cut view of the water block shows the early thermal hydraulics structure, where the completely smooth base surface forms a reservoir with the cover:

2011

Unlike other providers we maintain complete control of our value chain which means that we can offer cutting-edge solutions at a very competitive price and this is very important to our customers.

During this period, we still designed our water blocks internally and manufactured them externally. The optimal performance for this generation of water blocks is 60W with a water temperature of 30°C.

Our water blocks continued to evolve. We replaced the copper convex end base plate with a simple plate. The cross on the cap was replaced by a cross inside the water block. This allowed us to further reduce the cost of the water blocks without impacting performance.

2013-2014

We always try to be innovative and forge our own path. Since 2013, we have continuously rethought our water-cooling technology, improving performance, operation and cost. This constant innovation allows us to keep up with our customers’ ever-growing demands for increased computing and data-storage capacities, and the ever-increasing amount of heat generated.

The water blocks created in this period were completely different from earlier generations. We replaced welding by screw-based tightening, and the convex top plates were replaced with plates with integrated water inlets and outlets.

Other factors

At this stage, we began to make water block variations, for example adapting them to the smaller GPU form-factors:

Here you have a side-by-side comparison of the standard, CPU water block, and the more compact GPU water block:

We also developed several special water block designs, adapted for specific constraints:

A good example is the water block we developed for the high density IBM Power 8 CPUs. In the next picture you can see this special water block’s cover and base plates:

2015 and beyond

The previous paragraphs described our water block technology in 2014. Since then we have come a long way. We have used new technologies like 3D printing, and made some fundamental changes to the design.

In the coming weeks we will publish the next posts in our water-cooling series. These will tell the story of how our water blocks have evolved since 2015. We will focus on the current generation and give you a sneak peek of the improvements to come.

Keep an eye out for our next post to learn more about OVHcloud water cooling!

Collaborative research at OVH through a thesis

A CIFRE thesis means, in French, Convention Industrielle de Formation par la Recherche, literally Industrial Convention for Training through Research. The aim is to encourage research collaboration between private and public entities. For enterprise and PhD students, CIFRE is a means of training through research and acquiring strong scientific expertise. For academics, it is a means of managing a new PhD and of applying research results on an economic case. ANRT association manage the CIFRE thesis.

OVH and ORKAD, a research team specialized in combinatorial optimization and knowledge extraction launched a collaboration through a CIFRE thesis.

AutoML, as an example of an AI thesis

The thesis is entitled “MO-AutoML: a multiobjective framework to automatically configure Machine Learning pipelines“. MO stands for Multi-Objective and AutoML for Automated Machine Learning.

Machine Learning is a field of artificial intelligence used for a wide scope of applications like health prediction, shape recognition in embedded systems (e.g., autonomous car), marketing strategy selection, anomaly detection (e.g., temperature in a datacentre). Machine Learning algorithms are very efficient at exploiting data and extracting knowledge used to support decisions.

The main problem with these algorithms, is the technical challenge involved in selecting and tuning algorithms for good performance. That’s why the field of AutoML has emerged, in order to tackle this challenge by automatically selecting and optimising the ML algorithm. Also, AutoML aims to automatically solve other problems related to the field of Machine Learning, such as data formatting, explaining the results (e.g., feature importance), industrialising models, and so on.

Another problem with the current AutoML solutions, is that they are mainly single-objective. However, it can be very interesting to take several metrics measuring the quality of the model in addition to exogenous metrics, and let the user select the model in order to better address the basic problem.

This thesis aims to advance the issues mentioned above, thus facilitating and improving the use of AutoML.

OVH and AI

Certainly, the AutoML thesis will have multiple consequences for OVH. From now, our work on Machine Learning has allowed us to launch, Prescience, in our Labs. Prescience is a distributed and scalable platform that allows the user to build, deploy and query ML models.

As a result of strong collaboration with private partner NVIDIA, OVH provides the NVIDIA GPU Cloud (NGC) software platform as a European exclusive. The purpose of this partnership is to facilitate access to artificial intelligence by allowing users to run their processing, through NGC, on NVIDIA products hosted on the OVH infrastructure.

Prescience supports various kinds of problems, such as regression, classification, time series forecasting, and soon, anomaly detection. Problem resolution is handled through the use of both traditional ML models and neural networks.

Prescience is currently used at production scale to solve various challenges faced by OVH, and its alpha version is available to explore for free at OVH Labs. In this blog post, we will introduce Prescience, and walk you through a typical workflow along with its components. An in-depth presentation of the components will be available in future blog posts.

The inception of Prescience

At some point, all Machine Learning projects face the same challenge: how to bridge the gap between a prototype Machine Learning system, and its use in a production context. That was the cornerstone of the development of a Machine Learning platform within OVH.

Production notebooks

More often than not, data scientists design Machine Learning systems that include data processing and model selection within notebooks. If they’re successful, these notebooks are then adapted for production needs by data engineers or developers. This process is usually delicate. It is time-consuming, and must be repeated each time the model or the data processing requires an update. These issues lead to production models that, though ideal when delivered, might drift from the actual problem over time. In practice, it is common for models to never be used in a production capacity, in spite of their quality, just because the data pipeline is too complicated (or boring) to take out of the notebook. As a result, all the data scientists’ work goes to waste.

In light of this, the first problem Prescience needed to solve was  how to provide a simple way to deploy and serve models, while allowing monitoring and efficient model management, including (but not limited to) model retraining, model evaluation or model querying through a serving REST API.

Enhanced prototyping

Once the gap between prototyping and production was bridged, the second objective was to shorten the prototyping phase of Machine Learning projects. The base observation is that data scientists’ skills are most crucial when applied to data preparation or feature engineering. Essentially, the data scientist’s job is to properly define the problem. This includes characterising the data, the actual target, and the correct metric for evaluation. Nonetheless, model selection is also a task handled by the data scientist – one which delivers a lot less value from this specialist. Indeed, one of the classics way of finding a good model and its parameters still is to brute-force all possible configurations within a given space. As a result, model selection can be quite painstaking and time-consuming.

Consequently, Prescience needed to provide data scientists with an efficient way to test and evaluate algorithms, which would allow them to focus on adding value to the data and problem definition. This was achieved by adding an optimisation component that, given a configuration space, evaluates and tests the configurations within it, regardless of whether they’ve been tweaked by the data scientist. The architecture being scalable, we can quickly test a significant number of possibilities in this way. The optimisation component also leverages techniques to try and outperform the brute-force approach, through the use of Bayesian optimisation. In addition, tested configurations for a given problem are preserved for later use, and to ease the start of the optimisation process.

Widening the possibilities

In a company such as OVH, a lot of concerns can be addressed with Machine Learning techniques. Unfortunately, it is not possible to assign a data scientist to each of these issues, especially if it has not been established whether the investment would be worthwhile. Even though our business specialists have not mastered all Machine Learning techniques, they have an extensive knowledge of the data. Building on this knowledge, they can provide us with a minimal definition of the problem at hand. Automating the previous steps (data preparation and model selection) enables specialists to swiftly evaluate the possible benefits of a Machine Learning approach. It is then possible to adopt a quick-win/quick-fail process for potential projects. If this is successful, we can bring a data scientist into the loop, if necessary.

Prescience also incorporates automated pipeline management, to adapt the raw data to be consumed by Machine Learning algorithms (i.e. preprocessing), then select a well-suited algorithm and its parameters (i.e. model selection), while retaining automatic deployment and monitoring.

Prescience architecture and Machine Learning workflows

Essentially, the Prescience platform is built upon open-source technologies, such as Kubernetes for operations, Spark for data processing, and Scikit-learn, XGBoost, Spark MLlib and Tensorflow for Machine Learning libraries. Most of Prescience’s development involved linking these technologies together. In addition, all intermediate outputs of the system – such as pre-processed data, transformation steps, or models – are serialised using open-source technologies and standards. This prevents users from being tethered to Prescience, in case it ever becomes necessary to use another system.

User interaction with the Prescience platform is made possible through the following elements:

• user interface
• python client
• REST API

Let’s take a look at a typical workflow, and give a brief description of the different components…

Data ingestion

The first step of a Machine Learning workflow is to ingest user data. We currently support three types of source, which will then be extended, depending on usage:

• CSV, the industry standard
• Parquet, which is pretty cool (plus auto-documented and compressed)
• Time-Series, thanks to OVH Observability, powered by Warp10

The raw data provided by each of these sources is rarely usable as-is by Machine Learning algorithms. Algorithms generally expect numbers to work with. The first step of the workflow is  therefore performed by the Parser component. The Parser’s only job is to detect types and column names, in the case of plain text formats, such as CSV, although Parquet and Warp10 sources include a schema, making this step moot. Once the data is typed, the Parser extracts statistics, in order to precisely characterise it. The resulting data, along with its statistics, is stored in our object storage backend – Public Cloud Storage, powered by OpenStack Swift.

Data transformation

Once the types are inferred and the statistics extracted, the data still usually needs to be processed before it’s Machine Learning-ready. This step is handled by the preprocessor. Relying on the computed statistics and problem type, it infers the best strategy to apply to the source. For instance, if we have a single category, then a one-hot-encoding is performed. However if we have a  a large number of different categories, then a more suited processing type is selected, such as level/impact coding. After being inferred, the strategy is applied to the source, transforming it into a dataset, which will be the basis of the subsequent model selection step.

The preprocessor not only outputs the dataset, but also a serialised version of the transformations. The chosen format for the serialisation is the PMML (Predictive Model Markup Language). This is a description standard to share and exchange data mining and Machine Learning algorithms. Using this format, we will then be able to apply the exact same transformation at serving time, when confronted with new data.

Model selection

Once a dataset is ready, the next step is to try and fit the best model. Depending on the problem, a set of algorithms, along with their configuration space, is provided to the user. Depending on their skill level, the user can tweak the configuration space and preselect a subset of algorithms that better fit the problem.

Bayesian optimisation

The component that handles the optimisation and the model selection is the optimisation engine. When starting an optimisation, a sub-component called the controller creates an internal optimisation task. The controller handles the scheduling of the various optimisation steps performed during the task. The optimisation is achieved using Bayesian methods. Basically, a Bayesian approach consists in learning a model that will be able to predict what is the best configuration. We can break down the steps as follows:

1. The model is in a cold state. The optimiser returns the default set of initial configurations to the controller
2. The controller distributes the initial configurations over a cluster of learners
3. Upon completion of the initial configurations, the controller stores the results
4. The optimiser starts its second iteration, and trains a model on the available data
5. Based on the resulting model, the optimiser outputs the best challengers to try. Both their potential efficiency, and the amount of information it will provide to improve the selection model are considered
6. The controller distributes the new set of configurations over the cluster and waits for new information, a.k.a newly-evaluated configurations. Configurations are evaluated using a K-fold cross-validation, to avoid overfitting.
7. When new information is available, a new optimisation iteration is started, and the process begins again at step 4
8. After a predefined number of iterations, the optimisation stops

Model validation

Once optimisation is completed, the user can either launch a new optimisation, leveraging the existing data (hence not starting back to the cold state), or select a configuration according to its evaluation scores. Once a suitable configuration is reached, it is used to train the final model, which is then serialised in either a PMML format, or the Tensorflow saved model format. The same learners that handled the evaluations perform the actual training.

Eventually, the final model is evaluated against a test set, extracted during preprocessing . This set is never used during model selection or training, to ensure that computed scoring metrics are unbiased. Based on the resulting scoring metrics, the decision can be made to use the model in production or not.

Model serving

At this stage, the model is trained and exported and ready to be served. The last component of the Prescience platform is Prescience Serving. This is a web service that consumes PMML and saved models, and exposes a REST API on top. As transformations are exported alongside the model, the user can query the newly deployed model using the raw data. Predictions are now ready to be used within any application.

Model monitoring

In addition, one of the characteristic features of Machine Learning is its ability to adapt itself to new data. Contrary to traditional, hardcoded business rules, the Machine Learning model is able to adapt to the underlying patterns. To do this, the Prescience platform enables users to easily update sources, refresh datasets, and retrain models. These lifecycle steps help maintain model relevance regarding the problem that needs solving. The user can then match its retraining frequency with newly-qualified data generation. They can even interrupt the training process in the event of an anomaly in the data generation pipeline. Each time a model is retrained, a new set of scores is computed, and stored in OVH Observability for monitoring.

As we outlined at the beginning of this blog post, having an accurate model does not give any guarantees about its ability to maintain this accuracy over time. For numerous reasons, model performance can weaken. For example, the raw data can decrease in quality, some anomalies can appear in the data engineering pipelines, or the problem itself can drift, rendering the current model irrelevant, even after retraining. It is therefore essential to continuously monitor model performance throughout the entire lifecycle, to avoid making decisions based on an obsolete model.

The move towards an AI-driven company

Prescience is currently used at OVH to solve several industrial problems, such as fraud prevention and predictive maintenance in datacentres.

With this platform, we plan on empowering more and more teams and services at OVH with the ability to optimise their processes through Machine Learning. We are particularly excited about our work with Time Series, which has a decisive role in the operation and monitoring of hundreds of thousands of servers and virtual machines.

The development of Prescience is conducted by the Machine Learning Services team. MLS is composed of four Machine Learning engineers: Mael, Adrien, Raphael, and myself. The team is supervised by Guillaume, who helped me design the platform. In addition, the team includes two data scientists, Olivier and Clement, who handled internal use cases and provided us with feedback, and finally, Laurent: a CIFRE student working on multi-objective optimisation in Prescience, in collaboration with the ORKAD Research Team.