100 Infrastructure basics

Updated . Posted . Visible to the public.

opscomplete

Our opscomplete gives you everything necessary to run a modern web infrastructure in a professional manner.
You have the application code, we take care of everything else. We have a private cloud running hundreds of sites but also support running and maintaining your application on AWS.

Architecture

Image

Data center location

Our data center is located entirely within Germany and, consequently, the EU.

Network Connectivity

Public

Our infrastructure is connected to the data center backbone via redundant 10 Gbit/s uplinks. The data center's carrier-neutral network has a total capacity of 48 Tbit/s and is redundantly connected to all major peering points, including DE-CIX.

Internal

Internal bandwidth is not limited by the network itself. To protect the stability of the platform, each VM's network bandwidth is limited by default. If your application needs more internal bandwidth, we're happy to raise the limit. If we notice a VM constantly running at its limit, we'll reach out to discuss increasing it.

Traffic

Public

The default setup includes 1000 GB of public traffic.

Internal

Internal traffic has no traffic limit.

Possibilities

Redis/Sentinel

If you want a high-availability Redis setup, we offer Redis Sentinel with automatic failover.

We also operate Memcache and OpenSearch for your application.

Dedicated Database

Besides the shared database server we also offer dedicated database servers. We support MySQL/MariaDB and PostgreSQL, both with high availability, redundancy and automatic failover. Daily backups are always included; point-in-time recovery is available as a paid option.

SSL

We integrate the free Let's Encrypt certificates as well as fee-based commercial certificates.

Security

Updates

We install the latest updates for our systems on a weekly schedule. In the case of critical issues we install the security fixes or implement necessary mitigations as soon as possible, taking into consideration possible impact to production resources.

Connections

We rely on encrypted connections and follow best practices for cryptographic algorithms. We don't allow plain-text authentication and enforce public key authentication.

Database connections stay within the local network and aren't accessible from the Internet.

Availability

Load Balancer

We have a setup of three load balancing servers on separate physical hosts. They are capable of fast, automatic failover to cover any outages and offer round-robin, weighted and least-connections traffic distribution.

Application Server

Our default setup includes two application servers on separate physical hosts to achieve redundancy. Thus if one of the servers goes offline (failure, outage, planned maintenance) the application is still available and accessible on the other one. It's possible to scale vertically (add virtual resources) as well as horizontally (add servers), see here.

Database Server

Our default setup includes two database servers on separate physical hosts to achieve redundancy. Thus if one of the servers goes offline (failure, outage, planned maintenance) the databases are still available and usable.

Monitoring

We provide two sorts of monitoring:

Outage

We run automated 24/7 monitoring for all relevant resources and services so we can act fast on any issues. We're using Naemon Show archive.org snapshot for that purpose.

Performance

We run automated 24/7 performance monitoring to cover the need for adjustments regarding hardware resources. We're using collectd Show archive.org snapshot , graphite Show archive.org snapshot and grafana Show archive.org snapshot for that purpose.

Backups

We provide daily backups of databases and data stored in GlusterFS from the application servers. Upon request, we back up additional filesystem paths. Backups are stored in a separate fire compartment, physically isolated from the production systems. You'll find the details here: 500 Backup

Configuration Management

We use OpenVox Show archive.org snapshot , the community-maintained fork of Puppet, for configuration management. This gives us documented configuration with a full history of changes. The configuration on the server is defined by OpenVox and we can guarantee a solid and stringent state of your servers. This also assures that each of your application servers for your project is the same.

Profile picture of Thomas Eisenbarth
Thomas Eisenbarth
Last edit
Kim Klotz
License
Source code in this card is licensed under the MIT License.
Posted by Thomas Eisenbarth to opscomplete (2017-03-31 11:30)