Best way to use pro network
Moderators: Max, TerryRogers
Best way to use pro network
if epim is used in a lan the server machine must be always on just to have epim clients always updated so it's like to use a server machine only for epim.
1) so it's better to use a NAS . but which one do you advice (for a small office) just to have epim on it?
2) is there a way to bring the network edition like if it is on a cloud and to access to it everywhere and everytime? for example from house to the office on the database?
3) there is also the portable solution.... if we have always the pen with us . but epim has the app on the phone, more easy to have all we need in the hand, so is there a way to synch the app with the server?
thanks in advance
kind regards
1) so it's better to use a NAS . but which one do you advice (for a small office) just to have epim on it?
2) is there a way to bring the network edition like if it is on a cloud and to access to it everywhere and everytime? for example from house to the office on the database?
3) there is also the portable solution.... if we have always the pen with us . but epim has the app on the phone, more easy to have all we need in the hand, so is there a way to synch the app with the server?
thanks in advance
kind regards
Re: Best way to use pro network
but also using a NAS seems to be not the best solution: A Firebird database server should be a dedicated server and should only be responsible for the Firebird database service in order to ensure maximum performance.
Hardware related issues
Using a Firebird server with the database on an external SAN/NAS Drive is a bad idea, since the speed of a Firebird database server depends on the speed of access to individual 4k blocks on the device. As I mentioned, external SAN/NAS Drives are great for transferring hundreds of MB of data from one file location to another. However the Firebird server transfers hundreds of thousands of small pages between memory and physical hard disk found on different file offsets.
On a classic mechanical hard drive you have to consider the access time of the hard drive to be the limiting factor, because a commit writes data in very different file offsets. A RAID does not improve this; the head position must change in the same way. Caching RAIDS improve it but, with a high workload, they can sometimes increase the problems.
Classic hard drives have at least 5ms average seek time, which results in a maximum of 200 IOPS, the new standard for measuring faster devices.
An SSD (especially enterprise SSD) allows much more IOPS (up to 500,000 on PCIe-based hardware). An SSD built in the dedicated database server, which is not virtualized, is the optimal solution for maximum performance.
Example configuration
CPU: Intel Xeon E3 or E5 (non-threaded versions are OK)
RAM: 8GB or more (ECC is OK, but not required)
DRIVES: All SSDs should be enterprise level certified by the manufacturer: 1 SSD for the OS, 1 SSD for the database server, 1 Hot Plug SSD for an active shadow, optional 1 hot plug SSD for a part-time shadow as a backup replacement. When the database server and shadow SSDs reach an age of 2 years, they should be replaced to avoid unplanned failure (in server systems, we recommend the same for classic hard drives). The size of the SSDs should be 400% of your current database size or higher.
OS: WIn7 64 Pro is OK, no file shares or any other MS services except RDP should be active, no antivir, no online backup or imaging software etc. Shutdown all unused services, especially Windows updates. File system access should be managed by an FTP server, for example FileZilla, to transfer backup files to the external company backup solution. Linux is also OK, but it does have a much wider variety of potential problems. We prefer stripped Win7x64 Systems. Win2008R2x64 is also OK.
RAMDISK: For LCK and TMP Directory, a RAM Disk is very useful. For RAM Disk use, the physical memory should be increased to 16GB or 32GB. More is not required. A free RAM Disk software can be recommended on request.
REPLICATION: Optional: A replication system implemented by IBExpert can ensure transaction-safe clustering. A backup or shadow solution requires admin operations to restart the server on a second server in case of a severe hardware failure.
A replicated cluster enables work on the backup server with no loss of data. This requires some changes in the database and perhaps also in the system architecture. IBExpert can support the software manufacturer in the implementation process. A replication solution based on our technology is a separate project.
Important
A Firebird database server should be a dedicated server and should only be responsible for the Firebird database service in order to ensure maximum performance. Virtual servers lose between 20% and 80 % of their speed under a high load on a VM. Any advantage of a VM-based Firebird Server will be paid for dearly by all employees waiting additional time to carry out and complete their jobs.
http://ibexpert.net/ibe/index.php?n=Doc ... mendations
Hardware related issues
Using a Firebird server with the database on an external SAN/NAS Drive is a bad idea, since the speed of a Firebird database server depends on the speed of access to individual 4k blocks on the device. As I mentioned, external SAN/NAS Drives are great for transferring hundreds of MB of data from one file location to another. However the Firebird server transfers hundreds of thousands of small pages between memory and physical hard disk found on different file offsets.
On a classic mechanical hard drive you have to consider the access time of the hard drive to be the limiting factor, because a commit writes data in very different file offsets. A RAID does not improve this; the head position must change in the same way. Caching RAIDS improve it but, with a high workload, they can sometimes increase the problems.
Classic hard drives have at least 5ms average seek time, which results in a maximum of 200 IOPS, the new standard for measuring faster devices.
An SSD (especially enterprise SSD) allows much more IOPS (up to 500,000 on PCIe-based hardware). An SSD built in the dedicated database server, which is not virtualized, is the optimal solution for maximum performance.
Example configuration
CPU: Intel Xeon E3 or E5 (non-threaded versions are OK)
RAM: 8GB or more (ECC is OK, but not required)
DRIVES: All SSDs should be enterprise level certified by the manufacturer: 1 SSD for the OS, 1 SSD for the database server, 1 Hot Plug SSD for an active shadow, optional 1 hot plug SSD for a part-time shadow as a backup replacement. When the database server and shadow SSDs reach an age of 2 years, they should be replaced to avoid unplanned failure (in server systems, we recommend the same for classic hard drives). The size of the SSDs should be 400% of your current database size or higher.
OS: WIn7 64 Pro is OK, no file shares or any other MS services except RDP should be active, no antivir, no online backup or imaging software etc. Shutdown all unused services, especially Windows updates. File system access should be managed by an FTP server, for example FileZilla, to transfer backup files to the external company backup solution. Linux is also OK, but it does have a much wider variety of potential problems. We prefer stripped Win7x64 Systems. Win2008R2x64 is also OK.
RAMDISK: For LCK and TMP Directory, a RAM Disk is very useful. For RAM Disk use, the physical memory should be increased to 16GB or 32GB. More is not required. A free RAM Disk software can be recommended on request.
REPLICATION: Optional: A replication system implemented by IBExpert can ensure transaction-safe clustering. A backup or shadow solution requires admin operations to restart the server on a second server in case of a severe hardware failure.
A replicated cluster enables work on the backup server with no loss of data. This requires some changes in the database and perhaps also in the system architecture. IBExpert can support the software manufacturer in the implementation process. A replication solution based on our technology is a separate project.
Important
A Firebird database server should be a dedicated server and should only be responsible for the Firebird database service in order to ensure maximum performance. Virtual servers lose between 20% and 80 % of their speed under a high load on a VM. Any advantage of a VM-based Firebird Server will be paid for dearly by all employees waiting additional time to carry out and complete their jobs.
http://ibexpert.net/ibe/index.php?n=Doc ... mendations
-
- Site Admin
- Posts: 17210
- Joined: Thu Nov 25, 2004 3:12 am
- Has thanked: 1618 times
- Been thanked: 1139 times
Re: Best way to use pro network
1. The answer is in your second post. Can confirm correctness of info.
2. You can do that with the cloud, although it wouldn't be possible to replace Network edition if you need to assign different permissions to different users.
3. Yes.
Thanks.
2. You can do that with the cloud, although it wouldn't be possible to replace Network edition if you need to assign different permissions to different users.
3. Yes.
Thanks.
Android version of EssentialPIM. Keep all your data in sync!