Hosting a web application and choosing the plan

Domains and Hosting
,
1

Hello,

I am posting a message here about a new tool we are developing for scientific research. It is a web application with a database. I am a researcher, not a technician, so I apologise in advance for any approximations.

We have in mind an infrastructure that must meet the CNRS security standards (i.e., ANSSI).

  • One machine for the application and one machine for the database (plus two redundant machines).
  • Log backup for all machines (system logs and application logs for a rolling 1‑year period).
  • One pre‑production machine.
  • VPN access to the machines as well as an SSH Bastion for server administration.

A few questions (these are points I couldn’t get clarification on in the offer or over the phone with sales):

  • Only the application machine should be accessible from the outside for users; all other machines must be reachable only through the Bastion (or via the application when it interacts with the database).
  • The application and the database are really lightweight; we do not need large servers at all (we are even wondering if VPS‑2 or VPS‑3 would be sufficient). There could be a bit of traffic on the tool, but it is unlikely to exceed a thousand concurrent users.
  • If I understand correctly, the backup creates a daily snapshot that is kept for 14 days and can be restored at any time, is that right?
  • We have a maximum downtime target of 24 hours. To meet this, we plan to have redundancy for the application and the database. But is this really necessary given OVH’s backup offering? For example, if a server were to fail, does OVH usually take more than 24 hours to bring up a machine on which we could reinstall the backup? If OVH can provide emergency machines in case of an incident to restore backups, the redundancies might not be needed.
  • Is the ability to take manual snapshots of the machines (e.g., before an update) included in the offers?
  • Are the VPN and Bastion access included (I admit I don’t fully understand OVH’s IAM approach)?

In general, I wonder how OVH works with projects like this: do they only provide the servers/VMs, or do they also set up the infrastructure and the connections between the various machines, backups, logs, bastions, etc.?

Thank you for your help,

Have a good day!

2

Hey,

That's quite a serious infra you're looking to set up, you'll need to articulate the real needs, design the architecture and then manage it.

My two cents on some points:

  • 1000 concurrent users can already be a lot :slight_smile:
  • 24 h max downtime is huge, so I don’t see the point of redundancy. Plan a solid backup policy and a good DR plan.
  • VPN, bastion config, network, etc. are not provided by OVH; you have to do it (nothing to do with IAM).
  • Maybe one or two servers with VMs or containers could do the job

You should hire an independent consultant / company to study the different options.
Could this interest @Sich?
You can check the OVH partner directory https://partner.ovhcloud.com/fr/directory/#partnerLocalization_element=1654%2C1661%2C1662 to find a provider.

3

Hum, we'd need to look at the requirements in detail.

I'm quite opposed to the fantasy of “bastions SSH” and other stuff like that, well, when the client wants...

Given the infrastructure, for my part, I'd avoid redundant servers, but on the other hand a solid BCP (business continuity plan), yes.

Either go with Public Cloud (public network, private network, snapshot, etc.), or bare‑metal but virtualized.

What about the real need to separate the DB server and the application? That adds latency, for a benefit that's not necessarily obvious.

Also need to see who will maintain the infrastructure once everything is in place; it's nice to set it up, but an infra needs maintenance.

And yes, 1,000 simultaneous users is a lot actually :slight_smile:

In short, for a quick answer I'd say Public Cloud.
But we need to look at the implementation budget, the maintenance budget.
ANSSI‑type craziness generally doesn't add much, but it adds constraints and therefore cost.