Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
TetraWiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Category:YOUSECURE
(section)
Category
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Training on YOUSECURE Project KT PART 1. Dated 19 April 2024 - Tetra Support Staff - Alok Singh== {{#ev:youtube|M7TdXod5lsE|640}} '''Video summary:''' "YOUSECURE Project KT PART 1" -- a Hindi-language architecture walkthrough of the YouSecure hosting environment, drawn on a whiteboard/diagram live during the call. YouSecure runs two parallel environments -- "eSign Production" and "Traditional Production" -- both LAMP-based (Linux/Apache/PHP) with separate MySQL database servers, and every server is deployed as an HA pair (e.g. a primary and an "A" duplicate with adjacent IPs, each with its own paired database). The network is split into a DMZ zone (a 192.168.1.x segment, holding the WAF and external HAProxy) and an MZ/internal zone (a 192.168.2.x segment, holding the internal HAProxy, the four LAMP web servers -- each serving a different client domain in the Traditional environment -- and the database servers), with NAT rules on the firewall exposing the private DMZ IPs to the internet. Request flow: internet -> WAF -> external HAProxy -> internal HAProxy -> the correct backend LAMP server per the HAProxy config's per-domain routing rules -> its paired database. HAProxy is configured for priority/failover order rather than even round-robin -- it sends all traffic to the primary backend and only fails over to the secondary if the primary goes down -- and the two MySQL databases behind each pair stay in sync via master-to-master replication so no data is lost on failover. A separate problem is also covered: because uploaded files (PDFs etc.) land only on whichever LAMP server actually handled the request, and the paired servers aren't otherwise replicated, a failover could leave the secondary server missing files the primary had received. This was solved with a shared NFS server -- both paired LAMP servers mount the same NFS-backed directory (e.g. the upload folder), so either server can read files regardless of which one originally wrote them. The eSign environment mirrors this exact design but with a smaller footprint (essentially one web server instead of four).
Summary:
Please note that all contributions to TetraWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
TetraWiki:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)