New Fluid Design and Fluid Evaluation pages and Fluid Architecture diagram

Please see the new Fluid Design and Fluid Evaluation pages. Original posts have been converted and updated as pages for constant updates. Suggestions and questions welcome on these and the Fluid Architecture diagram

Posted in Uncategorized | Leave a comment

EMA Monitoring Practices (Best is usually usual, not Best)

EMA Monitoring Practices (Best is usually usual, not Best)

External and self monitoring
monitor applications internal perspective
monitor apllications user perspective
monitor the monitoring
Monitor full infrastrcuture stack
monitor all functions of all Infrastructure components
monitor any application delivery points
Enable all device self monitoring / logging
No warnings – non actionable
Monitor by service / application not device type
Monitor every service running
Monitor every service port listening
Define Alerts – phones and mail, Notifications – mail, Reports – mail
Monitor to restore redundancy not availabiility
Monitor for procative capacity planning reporting
Monitor for IT Transparency all info to all departments – sales marketing executive
All monitoring to only standardized mail distribution lists with phone addresses
Configure monitoring dependancies
Configure monitoring escalations all the way to the CEO, why? CEO has a credit card
Document alert response processes
Monitor delveopment, staging, and production
Create Daily Weekly Monthly application resource usage capacity planning
Monitor all external services
Configure all external service monitoring / company contacts for standard mail distribution list
Monitor network services domain registration ssl ceertificates DNS
Alerts immediate action
Notifications business hours
Reports – business hours proactive

Posted in Uncategorized | Leave a comment

Fluid Computing – Evaluate, The Critical Missing Project Task

Post on the Evaluate, usually missed critical Project step in progress, expected by 1/1/18 as good a date as any to improve a default IT Project template

1. Vision
2. Requirements
3. Design
4. Evaluate
5. Proposal
6. Order
7. install
8. Configure
9. Monitor
10. Test
11. Production

Posted in Uncategorized | Leave a comment

Fluid Computing Product List

Fluid Computing Product List

Add a Product

Posted in Uncategorized | 1 Comment

Good to be Back…

I am glad to be back, its been a very long time, 7 years since the first posts and a lot has changed and incredibly a lot has stayed the same and Cloud Computing is still in debate.

Private Cloud is rapidly becoming more accepted as a component of Enterprise Hybrid Cloud and the failed promise of Public Cloud cost savings is now being commented as 4x the cost of Private Cloud. There has long been a saying buy the Base capacity, rent the Spike. Base. In other words Base capacity is the minimum Production Capacity, making Private Cloud the most critical component of the now consensus Hybrid / Multi Cloud optimum IT Strategy.

What I am working on now is an updated Private Cloud SDDC Architecture design template as a component of a Hybrid / Multi Cloud Architecture.

Posted in Uncategorized | Leave a comment

Enterprise Monitoring Architecture (EMA)

If you don’t Monitor you can’t manage and if you can’t manage you cant use it

Enterprise Monitoring Architecture
Scaleable, Vendor Agnostic, Monitoring Framework

Cloud computing, especially private/hybrid cloud computing, consists of shared hardware, so monitoring becomes much more critical. If a performance or capacity limit is reached, multiple applications will be affected. Unfortunately most companies dont monitor as much as they should because there isn’t a Monitoring or Alerting standard. The Enterprise Monitoring Architecture (EMA) is an open source vendor agnostic Monitoring / Observability framework to provide a solution for this. The purposes of EMA are proactive reliability management and immediate automatic root cause analysis, EMA eliminates troubleshooting. Datacenters with full redundancy are only alerted to redundancy degradation rather than outages and become much more of a Notification than an Alert reducing IT Staff stress   

An Enterprise Monitoring Architecture (EMA) is a combination of standardized alerts, notifications, and reports to achieve maximum availability.
Alerts are for a system status that is causing, or could cause, an immediate impact and go to text message and console 24 x 7
Notifications are for a system status that could cause an issue within a few business days and go to email only 8 x 5 business hours.
Reports are for capacity planning, which is critical for private cloud architecture provide information needed to extrapolate requirements for additional resources 

EMA is managed by configuring all monitoring sources with EMA email groups by enterprise organizations, categories, projects, and types. Information is communicated via mail groups containing text message and standard email addressees by Application and Infrastructure examples App1Alert, App1Notify, SREAlert, SRENotify, etc. These standardized EMA groups are configured in all IT systems, hardware, backup, 
anti-virus, updates, and monitoring systems The EMA groups include IT staff and everyone that uses the application so that everybody is aware of any performance issues. Changing members of the  email groups effectively changes the monitoring configuration of all Enterprise systems scaling to from a few to thousands of sources of monitoring information if needed

@ParkerCloud Twitter Monitoring Moments

  1. Create EMA Project plan in Smartsheet for public availability
    EMA Project Plan – Draft 122717
  2. Write Implementation Documentation
  3. Manage list of Monitoring Applications
    Application List

Link | Posted on by | Leave a comment

Private Cloud Design Rules

Private Cloud Design Rules
The design goals are to deliver maximum total IT efficiency, a combination of Cost Savings, Agility, Redundancy, and Efficiency (operational efficiency) All the rules are meant to be followed as one. The first rule of Private Cloud is to follow all rules, the more followed the better the result and following fewer gets exponentially worse results. The following rules create a virtual infrastructure meant to support a Private cloud management application to deliver Cloud functionality. Virtual Infrastructure alone is not a Private Cloud although it delivers much of the benefit of Private Cloud. My current recommendations for Private Cloud Management applications are Abiquo, Embotics, and VMware vCloud Automation Center (the software formerly known as Dynamic Ops)

Rule 1 Virtualize Everything
Routers, firewalls, load balancers, switches, backup …
You might wonder how to virtualize backup. Another way to think of virtual is multi-tenant so look for backup apps that supports notification by unique backup job and assign backup jobs by service / client. Some virtual devices like load balancers much less expensive than physical and enables better scalability and availability

Rule 2 Monitor (alerting and reporting) Everything
Every server, every service, every port, categorize alerts and reports by service / client.

Rule 3 No Tech Silos
All admins manage all components. Assign admins to service / client. Develop admins as well as engineers

Rule 4 Full Redundancy for all components
Redundant internet connections, routers , firewalls, switches, server ports, storage adapters, SAN controllers, datacenters…

Rule 5 Every component requires a web management interface
Enables remote administration from any device without admin software installation, develop admin expertise not command line expertise

Rule 6 Holistic Design
Iinclude all components in the design, every component should be selected to be Cloud design specific from remote access to backup, specifically VPN support and web admin interface

Rule 7 Design for Resource Density
Select devices for as much resource per rack U as available. Remember to consider CPU core density as much as socket density, for backup I suggest 2U LTO 16 cartridge libraries

Rule 8 Design for Functional Density
Select devices that offer multiple functionalities per rack U space, example Juniper SSG devices that combine router, firewall, VPN. Do not use dedicated router hardware unless necessary. Select virtual instead of physical devices, Netscaler load balancers for example.
Suggestion to combine vCenter and Backup server on the same physical server, VLAN tag to all subnets for all level2 backup traffic

Data Center
Rule 9 Datacenter not Server room
Private Clouds should be in datacenters not server rooms to provide cheaper and redundant bandwidth and Air, Power, etc infrastructure.

Rule 10 Standardized Datacenter Design – Datacenter Pods
Standardize datacenter hardware design 3, 5, 7 rack pod designs. Standardized management and capacity racks. Even a 3 rack design can provide up to app. 800 vServer capacity @ 800 Ghz and reasonable amount of associated storage and networking

Rule 11 More smaller datacenters than fewer bigger datacenters
Primary / Backup datacenter design is RAID 1, 100% redundancy cost. Six smaller datacenters RAID5 is app. 15% redundancy cost

Rule 12 Use Large Servers
Larger servers require less redundancy cost than smaller servers.
4 socket 16 core for core density, 2U, 6 IO slots 4 10gb net interfaces 16gb FC

Rule 13 No local hypervisor vServer storage
RAID 1 + hotspare  or USB only for hypervisor hosts, all vServers on SANs

 Rule 14 Full Virtual Infrastructure
Use virtual infrastructure like vmware vcenter and enable automatic high availability and distributed resource scheduling

Virtual Servers
Rule 15 Configure all vServers on SAN Storage
vServers should be on SAN Storage for redundant controllers and disks, scalability, and efficiency. Local storage does not offer redundant storage

Rule 15.1 Mix vServer types on the same hosts
Place multiple types of servers; App, DB, Mail, Web, etc. on the same hosts to level / balance utilization, reduce spikes

Rule 16 DHCP IP addressing
Use DHCP IP Addressing, yes even for servers

Rule 17 VLAN everything
Select only devices that support VLAN tagging not just the obvious but WAN optimizers, Load balancers, Remote Access devices

Rule 18 10Gb network
Select 10gb physical server interfaces, redundant of course and divide capacity with virtual switches for capacity density and cable reduction. Use 1U 24 Port 10Gb switches

Rule 19 Switch Clusters
Select switches that support clustering, virtual chassis composed of multiple switches and LACP that spans switches

Rule 20 All SAN Storage
See  vServers above, worth repeating and the same benefits for servers apply to virtual devices like load balancers as well

Rule 21 Standardized Datastores
Configure all 2TB.  vServer IO increased by striping across multiple datastores

Posted in Uncategorized | Tagged | Leave a comment