Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. IBM SmartCloud Camp 2011 Presentation<br />Team 3:<br />Terry Chang<br />Deepak<br />Wai Phyo Kyaw<br />Charlotte Ng<br />Desmond See<br />
  2. 2. Scenario 1: Problem Definition<br />To design 3-tier Application with features:<br />load balancing<br />failover<br />redundancy<br />scalability<br />secure<br />Solve single point of failure in our systems<br />
  3. 3. Scenario 1: Architectural Design<br />IBM HTTP SERVER<br />with WAS Plugin<br />IBM HTTP SERVER<br />with WAS Plugin<br />LOADBALANCER<br />LOADBALANCER<br />INTERNET<br />Websphere Application Server Cluster<br />App: Clone 1<br />App: Clone 2<br />Node 1<br />FIREWALL<br />App: Clone 3<br />App: Clone 4<br />IBM DB2 Server Cluster<br />IBM SAN (Redundant Disks: RAID 10)<br />Instance 1<br />Node 2<br />stores data<br />Instance 2<br />Deployment Manager<br />*instances will be created in different data centres around the world<br />
  4. 4. Scenario 1: Configuration in Instances<br />Assign Virtual IP <br />Install Pacemaker<br />Configure Heartbeat communication layer<br />Provision at least 2 number of VMs instances and get ready<br />In time of failure:<br />Reconfigure Virtual IP for the alive instance<br />Automatic direct traffic to the alive nodes<br />Fault-tolerance, fast recovery times, session replication<br />
  5. 5. Scenario 1: Advantages of IBM Cloud Systems<br />What and how did we leverage IBM Technologies?<br />IBM HTTP Server<br />Workload Management + Loadbalancer<br />IBM Websphere Application Server <br />Clustering, Automatic failover<br />IBM DB2 (with HADR/v9.5+)<br />Database Client Nodes Clustering with HADR<br />SQL Replication, Shared Disks/SAN Support<br />DB2 HA: DB2 High Availability Instance Configuration Utility (db2haicu)<br />IBM Storage Area Network SAN: RAID 1 or RAID 10 (not RAID 5)<br />Shared Disk redundancy<br />
  6. 6. Scenario 1: Design Considerations<br />Different Physical Locations of Instances<br />Automatic Trigger, Notification and Configuration<br />Data integrity after recovery/during failover/in SAN<br />Security in configuring/writing scripts<br />
  7. 7. Scenario 1: Project Management<br />Scope & Deliverables:<br />Complete implementation of high availability data recovery three-tier application on SCE : from architecture to scripting configurations<br />Configure WAS, DB2 instances and SAN nodes?<br />Configure automated scripts, Provision monitoring instances<br />Proposed Timeline:<br />100 man hours<br />5 persons team<br />Resource Estimation:<br />2 x firewall+loadbalancer, 2x IBM HTTP Server, 2x WAS Nodes, 2x DB2 Instances, 2x SAN Sites<br />Test Plan<br />Test instances failure (kill the services), Test recovery process (automation, time, data integrity)<br />
  8. 8. Scenario 1: Project Risks<br />Technical<br />Configured incorrectly during failover and recovery<br />Data integrity issues, session not replicated, data not copied properly<br />SCE issues?<br />Recovery time exceeds minimum as stated in SLA<br />Team<br />Inadequate skills, inexperience<br />Manpower shortage<br />
  9. 9. Scenario 2: Problem Definition<br />To build a scalable and multi-tenancy web portal as a platform<br />Customer self-management portal system<br />To provide SaaS to customer as an Independent Software Vendor<br />Simplified and standardized technical setup of the software for the customers <br />
  10. 10. Scenario 2: Intended Design<br />New User Registration/Login<br />APIs<br />- our own Business Logic (authentication, creating new account in DB)<br />
  11. 11. Scenario 2: Intended Design<br />Dashboard for Customer<br />** First, Create DeveloperCloudClient to execute requests against the Cloud | DeveloperCloudClientgetClient()<br />
  12. 12.
  13. 13. Scenario 2: Intended Design<br />Billing information<br />
  14. 14. Scenario 2: Project Management<br />Scope<br />Web portal<br />DB2 – (customer authentication and data storage)<br />Proxy server<br />Business logic<br />Deliverables<br />Create portal system with fully functioning interface<br />Create database integrated system + a relational database<br />Add security features to protect customers’ data<br />Modularized and loosely coupled system(Use of RESTful Services)<br />
  15. 15. Scenario 2: Test Process<br />Create multiple same Customer IDs<br />Create > 5 instances of VM which is over the limitation <br />Create Failover at either the SCE side or Proxy server.<br />Give wrong user credentials<br />Accuracy of the billings<br />
  16. 16. Scenario 2: Project Risks<br />Technical<br />Security – authentication between users and proxy server or proxy server and SCE<br />Failover and workload balance at SCE, proxy server<br />Connection timeout between client, proxy and SCE<br />Configuration error in creating the instances of the vm or application.<br />SCE unable to create instances or access<br />Team<br />Skill and knowledge inadequate<br />Illness, MC<br />Underestimation of projected timeline<br />Service level agreement<br />
  17. 17. Scenario 2: Advantages of Cloud Systems<br />Low total cost of ownership of the equipment<br />Flexible usage of the services : Pay Per Use, Utility Billing<br />High availability<br />Handle Variable Demand (Dynamic Load)<br />Pervasiveness (Anytime, anywhere)<br />
  18. 18. Scenario 2: Design Considerations<br />Customers information security<br />Standardization and automation<br />User friendly interfaces<br />Cost saving<br />
  19. 19. Scenario 3: Problem Definition<br />Aim: Provide information to managers and identifying poor/well-performing branches (acc to branch, then country, then continent)<br />Business problem: Unable to make adequate decisions because data is confusing and not presented in a readable format for further analysis<br />
  20. 20. Scenario 3: Dummy Data<br />Extracted, transformed and selected data from OLTP (ETL Process)<br />
  21. 21. Scenario 3: How Cognos can help Rainbow Food<br />Shopping experience:<br />Identify, report on and analyze trends <br />Use predictive models and association rules<br />Gain insight into customer perceptions of service, store, products and merchandising<br />Promotion and merchandise planning:<br />Optimize merchandise levels and inventory<br />Conduct market basket analysis<br />Develop plans for key financial indicators<br />Smarter operations:<br />Set, measure and monitor key performance metrics based on standard financial statements.<br />Use predictive models to improve recruitment and optimize staffing decisions.<br />Gain visibility into key metrics across the chain: sales, labor, inventory and promotions<br />Monitor turnover and employee productivity<br />
  22. 22. Scenario 3: Generated Reports <br />Expense and Revenue across Shifts<br />Product Sales over Five Years<br />
  23. 23. Scenario 3: Generated Reports <br />Geospatial analysis of performance of Rainbow Food outlets<br />for products, for staffing<br />
  24. 24. Scenario 3: Intelligence<br />Staff underutilization:<br />understand which area is understaffed during particular shifts<br />with maps and other outlets’ realtime data, we can relocate staff<br />instead of retrenching or letting them idle<br />Non-selling products: <br />different regions have different tastes<br />varies from time to time as well<br />remove unpopular food items from menu<br />analyze new food trends<br />Mashup (interconnected) intelligence:<br />import external datasets (eating habits, demographics, research agencies)<br />
  25. 25. Scenario 3: Leveraging Cloud Systems<br />Why Cognos, instead of Excel?<br />can handle large datasets<br />can draw data from different sources real-time<br />multiple parties can gain insights at the same time, share data<br />all stakeholders can access anytime anywhere<br />use LotusLive for collaboration (sharing of reports)<br />more transparency<br />
  26. 26. Scenario 3: Project Management<br />Scope: Create intelligent reports based on fusion of diverse data<br />Deliverables: User-friendly, collaborative, interactive reports<br />Timeline: 1 week (training) + 2 weeks (collection) + 1 weeks (report design) + 2 weeks (validation of reports)<br />Resources: Reliable datasets, BI Training and Tools, Commitment of analysts<br />Risks: Unfamiliar with Cognos, Garbage data, Context of data (food poisoning)<br />
  27. 27. Thank you :)<br />