Following on from the previous blog post ‘Whats This Pre Sales Thing All About?‘ which was aimed at understanding what a Pre Sales Engineer does, I thought it would be relevant to put together a blog post on the design considerations.
This isn’t meant to be a technical post, more so, what are the infrastructure pieces you should be questioning, so that your solution isn’t missing any essential pieces. This isn’t going to be a complete coverall, but hopefully should send you down the right path and get you asking more questions about your design!
Generally speaking, I normally lead with business considerations, this is trying to understand what the client is trying to achieve, essentially, what are you looking to achieve and anything that could influence the design.
- What is the business driver behind the work?
- Does the business have to comply with any legislation?
- Does the business comply with any governance such as infrastructure security risk policies?
- Does the business have plans for contraction or expansion over the next three to five years?
- Will the business be opening any new offices?
- Is the business considering any mergers or take overs?
- What growth is required from the infrastructure in terms of capacity and performance
- Anything else you think we should be made aware off?
These are often the reason you are sitting in front of the customer having a discussion about the infrastructure required for the new piece of software.
- List your applications in terms of priority.
- How long can these applications be out of action?
- Are you adding any new applications?
- What are the application inter dependencies?
- What applications are you upgrading/changing?
- Are any applications latency sensitive?
- Does application clustering need to be considered?
- How is the application going to be packaged?
- How is the application going to be delivered to the users device?
- How is the application going to be managed ongoing?
The network is key, always consider optimal routing paths e.g. if you have a managed firewall at a colo, but your DMZ sits in production. Consider having a firewall in production for the DMZ so that traffic from WAN > DMZ > LAN doesn’t trombone the VPLS/MPLS.
- What VLAN’s/subnet’s are used and for what purpose?
- What is the bandwidth between sites?
- What is the latency between sites?
- Are links Layer 2 or Layer 3?
- What routing protocols are used?
- Is QoS being used?
- What are you using for DHCP at each site, are relays in place?
- Does remote access need to be considered? If so who requires it?
- Is clientless access a requirement for remote access?
- Is two factor authentication a requirement?
- Does a reverse proxy need to be included to facilitate software such as Lync?
- Do load balancers (local/global) need to be considered?
- Are HA firewalls required with no session loss?
- Is IDS required?
- Are diverse WAN links required at all sites?
- What encryption/authentication is required for VPN’s?
- Does the encryption domain needed to be NAT’d?
- Is LACP being used between Core and Edge switches?
- Would stretching VLAN’s help the design for backups, replication, WAN failure?
- Are enough network ports available?
Almost as key as networking, consider your performance and capacity requirements now and also for the future.
- What capacity is required?
- What are the back end/front end IOPS?
- What latency is required?
- What is the read/write ratio and the write penalty?
- Is snapshot/replication needed if so does it need to be ‘sync’ or ‘a sync’?
- Can the SAN grow to meet the capacity/performance requirements?
- What availability does the SAN need to provide e.g. does it need to be clustered?
- Does the customer have an existing iSCSI/Fabric switches that can be utilized?
- Does block size need to be adjusted?
- Is VAAI a requirement?
- Is Thin Provisioning supported and can the SAN stay thin using T10 UNMAP?
- Is de-duplication a consideration?
- Does an existing SAN need to be decommissioned? If so how are the volumes/data going to be migrated?
If the storage and networking are right, then the vSphere design should be a walk in the park. Remember if you are performing a capacity assessment on a Windows Server 2003 environment and the customer is moving to Windows Server 2012, then you need to allow for extra to memory/cpu/disk to accommodate this.
Note any items already mentioned in previous sections, should also be considered for the vSphere environment.
- What redundancy is required? N+1, N+2 etc
- How many vCenter’s are needed?
- What database is going to be used for vCenter components?
- How many hosts are needed?
- How many virtual machines will be required?
- What is the memory overhead of the VM’s?
- Are queue depths a consideration? (How many VM’s will be placed on each datastore)
- Moving from VMFS3 to VMFS5?
- Considering host evacuation is scale up or out right?
- How are the hosts going to be patched?
- What permissions are required for vCenter?
- What service accounts are required to run all vCenter components?
- What networking is required at vSwitch level? LACP, Route based on virtual NIC load?
- Do we need to pass any devices through to VM’s directly?
- Do any VM’s require high performance/low latency guarantees?
- Are resource pools required?
- How is the vSphere environment going to be monitored?
- How may NIC’s are required for LAN,DMZ,WAN,iSCSI,NFS,vMotion,FT, Management?
- What identity sources are required for SSO?
- Do the default vCenter certificates need to be replaced?
- Which HA policy is most suitable?
- Do Storage DRS rules need to be considered?
- What Anti Affinity and Affinity rules are required?
- What firewall rules are required?
- What VM’s need to be restarted in what order if a failure occurs?
- Does VM monitoring need to implemented?
- How are alerts going to be generated?
- Where are any ISO’s etc going to be held?
- Is network traffic management or optimization required?
- Is boot from SAN a requirement?
- Is link state tracking required for downstream ports?
- Do MTU’s need to be considered?
- Does EVC mode need to be enabled?
- How many VM templates are needed?
- What VMDK types will be needed, Thick Eager Zeroed, Lazy Zeroed, Thin?
You have this ‘shiny’ new infrastructure how is going to be backed up?
- What RPO/RTO is required?
- Does the 3 backup copies, 2 onsite, 1 offsite rule apply?
- What’s the backup windows (if any)?
- What backup media is going to be used?
- What types of backups are required, full, incremental, differential, reverse etc?
- How are the backups going to get from source to destination?
- What backup throughput is needed?
- What impact can backups have on production servers during working hours?
- Do backups need to be available in DR?
- Does backup validation need to be considered (will the backups work if needed)?
This is one of the broadest subjects that can be narrowed down quickly by asking the right questions.
- What is the impact to the business if you aren’t able to work for 24, 48 and 72 hours?
- Does all of data need to be available in DR?
- Do all the servers need to be able to run in DR?
- Do you need the ability to perform test failovers?
- What is the data change rate?
- What is the time frame allowed to have users up and working in DR?
- What percentage of users need to work in DR?
- What severs need to be running DR on a permanent basis e.g. SQL, vCenter, DC
- Are you willing to accept a performance hit in DR?
- How are you going to failover services such as email/remote access?
- Will the servers subnets/IP address’s/default gateway/DNS need to change?