Hardware

From regify WIKI
Revision as of 09:21, 2 February 2022 by Regify (talk | contribs) (→‎Virtual Hardware Requirements)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 supported virtualization host that is able to run the regify Provider Appliance. You will find a list of all supported virtualization hosts on the regify Provider Appliance page.

Virtual Hardware Requirements

We strongly recommend to use virtualization. You can find more information about the supported virtualization environments on this page.

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. See below.

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

  • 2 or more CPU cores (64 bit, amd64 or intel64 compatible)
  • 2GB of RAM (4GB if regibox is used)
  • 10GB of hard-disk space (20GB if regibox is used)
  • A virtual CD-ROM drive for mounting our ISO (mandatory for setup only)
  • Access to the machine console/window (mandatory for setup only)

If the number of users and usage increases, it might be needed to increase he number of CPU

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!
  • Must be available by the provider appliance in the internal network (eg NAS, SAN, no public drives supported).
  • regify providers V5 and newer supporting SMBv1 and SMBv2 protocol.

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

Redundancy

To achieve best redundancy on non-redundant environments, 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.

We often get asked about the 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.

Load-balancer Requirements

A load-balancer is not necessary, but highly recommended if you run a high redundant system with two regify provider hosts (see chart above). In case you plan to use one, 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.
  • transparently forwards http and https SSL connections (including Websocket protocols).
  • is also redundant (to prevent the load-balancer to be the 'single point of failure')

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 load-balancer 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.