Personal tools

Log in

Changes

From All n One's bxp software Wixi

Jump to: navigation, search

The bxp Infrastructure

280 bytes added, 11:33, 13 January 2017
no edit summary
= Overview = 
[[File:stacks_001.png|right|300px]]
The bxp software (bxp) infrastructure is a multi-tier design to delivery high availability with our own private infrastructure within Sungard Availability Services campus in Parkwest. [[Bxp_software_in_Sungard]]
For more information on stacks [https://www.intechnic.com/blog/which-technology-is-right-for-my-website/ | Stack Information]   
= Physical Infrastructure =
=Physical Infrastructure=
Sungard provide numerous high level interconnects to provide redundant Internet connectivity.
[[File:BER8SER2Infrastructure.png|800px]]
 
== Security ==  
The firewalls are implemented using Cisco 5510s.
== Load Balancing ==  
The load balancers are implemented using CentOS on a virtualised basis.
== Web ==  
The web servers are implemented using Windows Server 2008 R2 x64 on a virtualised basis.
== Database ==  
The database servers are implemented using Windows 2008 R2 x64 on a dedicated rack server basis.
= Logical Infrastructure ===Data Segregation==Within this common infrastructure data segregation is key. Though the solution uses a common infrastructure, logically the data is completely segregated. This segregation occurs at a web and database level.
== Data Segregation ==This area is often referred to as multi-tenancy or multitenancy. Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. In the case of bxp, the software does share common functionality, but each system is a separate instance, as is each separate database. [https://en.wikipedia.org/wiki/Multitenancy Wikipedia - Multitenancy]
Within this common infrastructure data segregation is key. Though the solution uses a common infrastructure, logically the data is completely segregated. This segregation occurs at a web and database level.
==Web segregation==
Each client is given their own unique folder within the web structure. Our demo system has the link https://ww3.allnone.ie/client/client_demo/main/login.asp. The client_demo part segregates the web file infrastructure uniquely. Each client has their own folder structure which is independent of all other systems.
This area is often referred to as multi-tenancy or multitenancy. Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. In the case of bxp, the software does share common functionality, but each system is a separate instance, as is each separate database. [https://en.wikipedia.org/wiki/Multitenancy Wikipedia - Multitenancy]
A set group of unique identifiers hard coded at the web layer ensures that database connections are only possible to one client database at a time. This is encoded into all operational pages of the solution.
== Web segregation ==
==Database segregation==
Each client has their own separate database. Each database begins with a common suite of tables making up the database structure independent of all other databases. As content is added each database grows according to the specific client needs.
Each client is given their own unique folder within the web structure. Our demo system has the link https://ww3.allnone.ie/client/client_demo/main/login.asp. The client_demo part segregates the web file infrastructure uniquely. Each client has their own folder structure which is independent of all other systems.
Each database is combined with the web segregation to provide full and unique audit trails for all interactions with that database. This is part of the design of the bxp solution.
A set group of unique identifiers hard coded at the web layer ensures that database connections are only possible to one client database at a time. This is encoded into all operational pages of the solution.
Backups of databases are unique to each client and encrypted separately. [[Bxp_Backups]]
== Database Strong security and operational procedure controls ensure this segregation ==is maintained by all personnel with access. All interactions are auditable.
Each client has their own separate database. Each database begins with a common suite of tables making up the database structure independent of all other databases. As content is added each database grows according to the specific client needs.
==Server Recovery Process from back-ups==Each database On request from All n One, the target server is booted by Sungard AS from an R1soft Live CD. The Sungard AS engineer is combined with prompted for information to enable the recovery software to connect to the R1Soft server. Once connected, the web segregation engineer chooses a server image to provide full recover and unique audit trails for all interactions with that databasea point in time to recover to. The necessary data (disk blocks) are then copied from the Disk Safe on the R1Soft server and written to the disk(s) on the target server. This Once this restoration process is part of complete, the design of target server can be rebooted without the bxp solutionLive CD and normal service is resumed (subject to any caveats e.  Backups of databases are unique g. software licensing tied to each client and encrypted separatelythe original server's UUID, MAC address changes, etc. [[Bxp_Backups]])
Strong security ==Server Patching Process==Servers are checked for patches and operational procedure controls ensure this segregation is maintained by all personnel with accessupdates daily. All interactions  These updates are downloaded and installed as soon as they are auditablespotted. The restart for the updates and patches to take effect is executed nightly.
 == Server Recovery Process from back-ups == On request from All n One, the target The database server is booted by Sungard AS from an R1soft Live CD. The Sungard AS engineer is prompted for information to enable the recovery software to connect to the R1Soft server. Once connected, the engineer chooses a server image to recover and a point in time to recover to. The necessary data (disk blocks) one exception where as updates are then copied from the Disk Safe on the R1Soft server installed weekly and written to the disk(s) on the target server. Once this restoration process is complete, the target server can be rebooted without the Live CD and normal service is resumed (subject to any caveats e.g. software licensing tied to the original server's UUID, MAC address changes, etcimplemented weekly.)
343
edits