Hardware

From regify WIKI
Jump to navigation Jump to search

hardware prerequisites

There are only a few fixed recommendations for running a regify provider, as it highly depends on your usage. Currently, you need a server (physical or virtual) that is able to run the regify Provider Appliance.

virtualization

Most common, a virtualized environment is used for hosting the regify-provider software appliance. We also recommend you to use virtualization. We are fine on using hardware, but take care about a redundant solution.

If you are not using a redundant virtualization environment, we recommend to use two different virtual hosts to serve two regify-providers and run them in cross-master replication mode.

To host a regify provider, the virtual server should offer at least

  • 2 or more CPU cores (64 bit, amd64 or intel64 compatible)
  • 8GB of RAM
  • 50GB of hard-disk space
  • Access to the machine console/window (mandatory!)

You can find more information about the supported virtualization environments on this page.

server hardware

There are no additional hardware requirements to the server, but we recommend a minimum of

  • x86 architecture (Intel or AMD compatible)
  • dual-core or better quad-core processor
  • 8 GB RAM
  • 240 GB hard-disk space
  • Hardware drivers need to be compatible to current RedHAT, CentOS systems

Two servers (with the above specification) together with a load-balancer are able to offer the service to a few thousands of regify-users with no problem.

regibox storage

If you plan to use/offer regibox, you will also need an additional SMB share available for the regify provider software appliance. The size of this SMB share depends on the amount of space you are planning to use and offer to your end users.

The SMB share...

  • needs to be redundant
    • Please make sure that the data is always available to the regify provider appliance.
  • needs to be big enough to cover all files of your customers
    • Please calculate the needed size by your needs, number of users planned and the limit you like to define as maximum space per user (MAXBOXSIZE).
  • needs to get backed up periodically.
    • Please make backups of your users data and reserve some separate space for some, at least, daily backup.
    • Do not use rsync style backups, because you need to be able to restore even files that were deleted before your backup was updated!
  • regify providers V4.x only supporting SMBv1 protocol. SMBv2 is only supported with regify provider V5 (Q2/2018) or newer.

If you are interested in how to activate regibox on your regify provider, please have a look here.

redundancy

We often get asked about redundancy decision. Therefore we created this chart to help you to identify your options: Redundancy decision graph for wiki.png

No matter what your decision will be, please always use the built-in backup option to create backups of the database and configuration. Please have a look into your regify provider appliance manual to learn how to configure it.

performance considerations

On normal usage, a single regify provider instance with up to date hardware is able to handle a few thousand users with no problem. But please respect, that the real capacity depends mainly on the way the regify provider is used. There are different scenarios that are heavily affecting the performance (like mass sending).

The overall performance depends on different factors:

  • product usage (regibox needs more resources than regimail)
  • internet connection bandwidth (the faster, the more performance)
  • usage-level (some users may not use regify every day, others surely will)
  • mass-sending (in that case, you need fast machines and Internet connection)
  • redundant setup (usage of a loadbalancer allows you to easily scale the solution)

Here you can find more information about the regify Provider Appliance.

networking traffic

As regify is not carrying the message content itself (it is transferred directly from the sender to the recipient using the existing e-mail infrastructure), the regify provider only needs to handle the regify related traffic like login information, keys and hashcodes, e-mail addresses etc. Upon this, it does not matter how big the regify message is.

There are four main types of traffic on a regify provider:

  1. register one regimail transaction -> ~7KB traffic
  2. open one regimail transaction -> ~6KB traffic
  3. using the web-portal -> depends mainly on users behavior
  4. regibox usage -> This mainly depends on the number of users and their usage (the better your connection the faster the sync of your users).

Please note that the measured traffic includes login and logout procedures. If you are sending a message to multiple recipients, the traffic will increase only very little. You also can reduce traffic by using the client Software Development Kit (SDK) which allows you to login once and then to register a few thousand messages in one session.

scalability

The regify-provider software is designed to get easily enlarged to fit grown needs of performance. The following options are available to boost performance by adding more hardware resources:

  • run a second regify provider appliance using database replication together with a loadbalancer to quickly double the performance.
  • add more CPU and memory to the underlying virtual machines or hardware. regify is mainly CPU intensive.
  • use SQL load-balancing to spread database access to multiple servers (Master-Slave, only for very high loads).

If you are planning a high performance solution, please feel free to contact us directly.

redundancy

To achieve best redundancy, we recommend you to set up at least two instances (real or virtual) on different physical hosts. To distribute the requests, a common load-balancer supporting session persistance will fit perfectly. Additionally, you can use two network routers to set up the two connections to the clearing-service.

load-balancer

A load-balancer is not necessary, but highly recommended if you run a high redundant system with two regify provider hosts. It needs to be able to

  • work "session based" or "session persistant" (route the same user to the same server) based on source IP address
  • allow SSL offloading (optional)