218 lines
4.1 KiB
Markdown
218 lines
4.1 KiB
Markdown
# On-Premises System Architecture
|
|
|
|
## Overview
|
|
|
|
This document describes the architecture for the **on-premises deployment of the application system**.
|
|
|
|
The system is hosted entirely within the company's internal infrastructure and is **not dependent on cloud services**.
|
|
|
|
The design prioritizes:
|
|
|
|
* local control of infrastructure
|
|
* internal network performance
|
|
* simplified deployment
|
|
* managed backups through **CBM Technology**
|
|
|
|
High availability and cloud failover are **not included** in this architecture.
|
|
|
|
---
|
|
|
|
# Architecture Overview
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
|
|
USER[Internal Users]
|
|
|
|
LAN[Company Network]
|
|
|
|
APP[On Prem Application Server]
|
|
|
|
DB[(Primary Database)]
|
|
|
|
BACKUP[CBM Backup System]
|
|
|
|
USER --> LAN
|
|
LAN --> APP
|
|
APP --> DB
|
|
|
|
APP --> BACKUP
|
|
DB --> BACKUP
|
|
```
|
|
|
|
---
|
|
|
|
# System Access
|
|
|
|
The application is accessed through the **internal network**.
|
|
|
|
Example:
|
|
|
|
```
|
|
https://app.avexmro.com
|
|
```
|
|
|
|
Remote access may be provided through a **VPN connection**.
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
|
|
USER[User Device]
|
|
|
|
VPN[VPN Connection]
|
|
|
|
LAN[Company Network]
|
|
|
|
APP[Application Server]
|
|
|
|
DB[(Database)]
|
|
|
|
USER --> VPN
|
|
VPN --> LAN
|
|
LAN --> APP
|
|
APP --> DB
|
|
```
|
|
|
|
---
|
|
|
|
# Infrastructure Components
|
|
|
|
## Application Server
|
|
|
|
The on-premises server hosts the application software.
|
|
|
|
Responsibilities include:
|
|
|
|
* serving the web interface
|
|
* processing application logic
|
|
* connecting to the database
|
|
* managing file storage if required
|
|
|
|
Typical deployment:
|
|
|
|
* Windows Server or Linux server
|
|
* Web server (IIS, Nginx, or Apache)
|
|
* Application runtime environment
|
|
|
|
---
|
|
|
|
## Database Server
|
|
|
|
The database stores all operational data for the application.
|
|
|
|
Examples of stored data:
|
|
|
|
* inventory records
|
|
* application configuration
|
|
* user accounts
|
|
* transaction history
|
|
|
|
In smaller deployments the database may run on the **same server as the application**, though separating them can improve performance.
|
|
|
|
---
|
|
|
|
# Network Layout
|
|
|
|
The application resides inside the company LAN.
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
|
|
USERS[Internal Workstations]
|
|
|
|
SWITCH[Network Switch]
|
|
|
|
SERVER[Application Server]
|
|
|
|
DB[(Database)]
|
|
|
|
USERS --> SWITCH
|
|
SWITCH --> SERVER
|
|
SERVER --> DB
|
|
```
|
|
|
|
Access is restricted to internal users or remote users connected via VPN.
|
|
|
|
---
|
|
|
|
# Backup System
|
|
|
|
Backups are managed by **CBM Technology** to protect against hardware failure, data corruption, or accidental deletion.
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
|
|
APP[Application Server]
|
|
|
|
DB[(Database)]
|
|
|
|
CBM[CBM Backup Storage]
|
|
|
|
APP --> CBM
|
|
DB --> CBM
|
|
```
|
|
|
|
Backups typically include:
|
|
|
|
* full server snapshots
|
|
* database backups
|
|
* file storage backups
|
|
|
|
---
|
|
|
|
# Backup Schedule
|
|
|
|
Typical backup configuration:
|
|
|
|
| Backup Type | Frequency |
|
|
| ------------------- | --------------------- |
|
|
| Database Backup | Daily |
|
|
| Server Snapshot | Daily |
|
|
| File Storage Backup | Daily |
|
|
| Retention Period | Defined by CBM policy |
|
|
|
|
Backups are stored **offsite** to protect against local disasters.
|
|
|
|
---
|
|
|
|
# Disaster Recovery
|
|
|
|
If the system fails due to hardware issues or data corruption:
|
|
|
|
1. The affected server is repaired or replaced.
|
|
2. The most recent backup is restored by **CBM Technology**.
|
|
3. Application services are restarted.
|
|
4. Users reconnect to the system.
|
|
|
|
Recovery time depends on:
|
|
|
|
* server replacement time
|
|
* backup restoration duration
|
|
* database size
|
|
|
|
---
|
|
|
|
# Limitations of This Architecture
|
|
|
|
Because the system is **single-site and non-redundant**, the following events may cause downtime:
|
|
|
|
| Event | Result |
|
|
| ----------------------- | -------------------------------------- |
|
|
| Server hardware failure | Application unavailable until restored |
|
|
| Power outage | System offline |
|
|
| Network switch failure | Users unable to access server |
|
|
| Database corruption | Restore from backup required |
|
|
|
|
---
|
|
|
|
# Potential Future Improvements
|
|
|
|
If higher reliability is required, the architecture could be expanded to include:
|
|
|
|
* secondary application server
|
|
* database replication
|
|
* network redundancy
|
|
* uninterruptible power supply (UPS)
|
|
* offsite disaster recovery infrastructure
|
|
|
|
These additions would move the system toward a **high availability architecture**. |