Kategoriak: All - database - backup - storage

arabera Sameera Kumar Gorenta 4 years ago

206

AWS Infra

In the AWS infrastructure, the Virtual Private Cloud (VPC) is utilized for both production and non-production environments. For production databases, Amazon RDS is deployed to handle critical database operations.

AWS Infra

AWS Infra

VPC 3

NON-PRODUCTION

RDS Details:

Database Engine: MySQL

Engine Version: 5.7.23

Port: 3306

Region & AZ: us-east-2a

Resource id: db-X4SAYZAJJGAYCVGYIGSMLRPH2Y

Instance class: db.t2.medium

vCPU: 2

Memory: 4 GB

Storage: 100 GB

Endpoint: theloanpost-dev.csym5hait0cq.us-east-2.rds.amazonaws.com

DB identifier: theloanpost-dev

VPC: vpc-de9b05b6

VPC security groups: appchromatics


Description:


This RDS consist of two database namely,

  1. theloanp_dev --> Dedicated for developers and testing team
  2. theloanp_stage --> Dedicated for US team.

Database Name: app.lendstacks_stage

Database Name: app.lendstacks_dev

Server 6

Non-Production Environment:


Instance ID: i-007ff14576eadd374

Public DNS (IPv4): ec2-18-217-247-251.us-east-2.compute.amazonaws.com

IPv4 Public IP: 18.217.247.251

Instance type: t2.medium

Elastic IPs: 18.217.247.251

Private DNS: ip-172-31-13-100.us-east-2.compute.internal

Availability zone: us-east-2b

Private IPs: 172.31.13.100

Security groups: appchromatics

AMI ID: ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-20180912

Monthly: $34.475


Description:

Here we have 3 set of application namely,

  1. Dev - For developers to test feature/ bug fix/ CR/
  2. Testing - For QA team to test code or application flow
  3. Staging - For US Team Testing the application {feature, bug fix and CR}

Staging

Testing

Dev

VPC 2

PRODUCTION DB
RDS

After forking the database this can be decided.

Database Name: app.lenstacks.com

VPC 1

PRODUCTION ENV
EC 2

Server 5

Esign/Upload Server


Created on: November 15, 2019 at 7:30:47 PM UTC+5:30

Instance ID: i-0ebe9695dbb081fab

Public DNS (IPv4): ec2-3-134-200-242.us-east-2.compute.amazonaws.com

IPv4 Public IP: 3.134.200.242

Instance type: t2.micro

Elastic IPs: 3.134.200.242

Private DNS: ip-172-31-21-121.us-east-2.compute.internal

Availability zone: us-east-2b

Private IPs: 172.31.21.121

Security groups: Upload_Server

VPC ID: vpc-de9b05b6

AMI ID: CentOS Linux 7 x86_64

E-sign/Upload Server

Server 4

NodeJS Server


Instance ID: i-021c1e480fa357fff

Public DNS (IPv4): ec2-3-14-154-251.us-east-2.compute.amazonaws.com

IPv4 Public IP: 3.14.154.251

Instance type: t2.large

Elastic IPs: 3.14.154.251

Private DNS: ip-172-31-39-121.us-east-2.compute.internal

Availability zone: us-east-2b

Private IPs: 172.31.39.121

Security groups: appchromatics

Monthly: $69.04

NodeJS Server

Server 3

Cron/Prod Server:


Instance ID: i-06679e2a87894ef55

Public DNS (IPv4): ec2-18-217-90-199.us-east-2.compute.amazonaws.com

IPv4 Public IP: 18.217.90.199

Instance type: t2.medium

Elastic IPs: 18.217.90.199

Private DNS: ip-172-31-27-170.us-east-2.compute.internal

Availability zone: us-east-2b

Private IPs: 172.31.27.170

Security groups: appchromatics

Monthly: $34.475


Purpose:

Running the cron job for vFax to trigger fax.

Fetching the google docs from NodeJS server and getting the merge tags value

Cron/Prod Server

CLB / ALB

Server 2

Replica Server

Replica will be same as prod(including all) but in different AZ so if in case an instance failed

this will be replacing the failed instance.

Replica App Server

Server 1

Application Server:

Application code server details:

Instance Type: Reserved(To reduce billing cost)

Core: c5n.2xlarge

Memory: 21 GB

Storage: 50 GB

The reason for choosing c5n.2xlarge instance because our application is php language

based, and php consume more cpu resource.

OS: Centos 6.10 or latest

Software Details:

Major:

Apache - 2.4v

MySQL - 5.7v (Support upto Oct, 2023)

Php - 7.2v (Support upto Nov, 2020)

Minor:

Curl

Imagemagick

other supporting softwaresAlso we will be enabling load balancer and auto scaling(Horizontal way)

Application Server

Route 53

Route 53


DNS Service

CloudWatch

CloudWatch:


It's an Alarm Service.


In case of any failure or issue mails will be triggered from cloudwatch service to customer(Chris/Sam/Kishore)

Failure Types:

1.Server Failure

2.Service Failure

3.Lambda service issues

Lambda

Storage

Storage

S3:

We use AWS S3 for storing the client documents, database dump, logs and backup(site backup, user data backup, etc)


(OR) can got with EFS for storing the Document which we have already tested in testing environment works good.


Related Document:


https://docs.google.com/document/d/1Xao2_HmNQausH6IDAjLoVhVOsl8T291mCb_ulvLCABk/edit


S3 GLACIER Deep Archive

S3 GLACIER Deep Archive:


S3 Glacier used saving the inactive LMRDocs for 180 days and then it will be automatically

removed from the bucket.

Database backup stored in S3 Glacier will be automatically removed after 90 days.

All logs such as access_log, err_log, db_logs and other services logs will be removed after

365 days.

Backups
Inactive Opportunity related Docs
S3 STANDRAD (OR) EFS

S3 STANDRAD

S3 Std used for saving the LMRDocs, PCuploadDocs, E-sign Docs and trustDocs.


Related Document:



https://docs.google.com/document/d/1Xao2_HmNQausH6IDAjLoVhVOsl8T291mCb_ulvLCABk/edit


Bucket 4 or Dir 4

E-SignDocs

Bucket 3 (or) Dir 3

Esigned docs

Bucket 2 (or) Dir 2

Organization Files or Docs

Bucket 1 (or) DIR 1

Opportunity Uploaded Files or Docs