Additional SugarCRM details for complete, functional, and portable deployment

1. Additional SugarCRM details for complete, functional, and portable deployment

2. EndPoint Deployment Requirements

3. Load Balancing • Some EndPoints in a tier may be load balanced • Load Balancing can typically be realized in the following ways: • Deploy another tier of one or more VMs with Load balancing software • Use the Load Balancing Service provide by the cloud by registering the load balanced VMs or any other programming • It should be possible to select among these in each deployment context

4. Load Balancing Abstractions Application Container Load Balancer Tier or Service WebServerTier Load Balancer VM 1 Port 80/443 HTTP/S EndPoint Virtual Service . . . . . . HTTP Client . . . VM n Aggregated Exposed EndPoint (publicly visible) . . . Load Balanced Connectors for each member of the pool Server Pool (all servers in the tier)

5. Virtual Service • Aggregates a set of EndPoints • Semantics • Protocol • HTTP, HTTPS, TCP • Session Stickiness • Bind requests from same client to specific server (or not) • Load distribution algorithm • Round robin, IP hash, least sessions, … • Health check • Determine if pool member is considered available or not

6. EndPoint Load Balancing • Tier is modeled as requiring load balancing along with required LB semantics for a specific EndPoint • Deployer tries resolve the requirement to a capability in the usual way • Deployer may deploy a new load balancing tier/service, use an existing tier/service, or use the cloud’s LB service to provide the capability

7. Firewall Update • The rules of all the firewall elements must be updated to allow access to the necessary EndPoints of the deployment • Firewall elements differ across clouds • Security Groups allow compartmentalizing sets of nodes • with large numbers (100s) or small numbers (5) available for allocation to deployments • Some clouds only use the firewalls in the server Oses • Customers may want the strongest enforcement requiring update of all firewall elements with the most restrictive access • Server network connectivity differs across clouds • Single interface with private IP address • Multiple interfaces, one with private and one with public IP address • Datacenters have networks for specific purposes: app, mgmt, backup, migration, DMZ, … • Static and dynamic IPs. IPs changing across restarts

8. Firewall Element Update • Compute complete deployment topology • Note this is done with the Instance Model (all Node Templates Instantiated) so we have all IP addresses • Determine which networks each connector will be bound to based on constraints. Simple case assumes single private network with complete connectivity and connectors with External EndPoints must be updated in Security Group • Assumes each exposed EndPoint is connected to an External EndPoint so we have complete set of connectors for all communication, but this an implementation detail • For each connector • For each firewall element it traverses • Update the element to allow the appropriate traversal

9. SugarCRM Topology Model Application Container WebServer Tier Database Tier VM FW VM HTTP Client . . . VLAN VLAN VM Operating System Firewall Elements Application Container VMs are assigned to one or more SecurityGroups

10. DNS and Public IPs • Public IPs usually need to be resolvable via DNS • This is typically done by one of: • Binding an IP address already known by DNS to the VM exposing the EndPoint • Updating the DNS service with the dynamic IP address of the VM exposing the EndPoint

11. SugarCRM Service Model SugarCRM Service WebServerTier DBServerTier Port 80 HTTP EndPoint Apache Web Server MySQL Required EndPoint Provided EndPoint HTTP Client SugarCRM App SugarCRM DB requires Typed Connector DocumentRoot:/SugarCRM HTTP Content EndPoint PHP Module Database Server EndPoint propagates client credentials, DB Name, host and port client EndPoint (Web Server) Server Admin Access and/or Management Access Zone1