Many organizations are currently using or seriously considering on adopting Cloud Computing as part of their infrastructure. The major advantages of cloud such as its scalability, rapid deployment and cost savings are attracting more customers from enterprise as well as in the SMB segment.
There are few concerns of Cloud Computing circling around the industry that the potential customers need to be aware of before making a business decision. This article discusses those concerns briefly:
• Availability – Any possible service interruption from the provider could severely impact the business. Users of Gmail for business have experienced this twice this year on March and September 09 for couple of hours. So know your cloud provider and their SLAs well before moving your business critical applications to cloud.
• Security – This is a huge concern for many in the IT industry considering the dynamic nature of the cloud. The area of concerns lies around the following :
o Confidentiality – Who has access to your data and application in the Cloud?
o Compliance - Where do your data and applications stored in the cloud?
o Liability – Who is liable in case of a security breach in your cloud infrastructure?
o E-discovery - Are the data and application immediately retrievable in case of a disaster at one data center?
o Perimeter/Host security – What type of security is implemented by the cloud provider on traditional DoS and other type of malicious attacks launched against the applications?
To overcome these concerns, there are best practices and solutions being developed by various vendors and non-profits in the Cloud Computing arena. They key one to be noted is Cloud Security Alliance.
HP, Cisco, IBM and Microsoft recently joined Cloud Computing Consortium to address the concerns. The article on this can be found here.
There are interesting articles in this area and few of them are listed below:
http://www.redbooks.ibm.com/abstracts/redp4614.html
http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-security-risks-853
http://www.computerweekly.com/Articles/2009/11/09/235782/Top-five-cloud-computing-security-issues.htm
Thursday, December 17, 2009
Friday, October 2, 2009
Friday, July 31, 2009
VMWare DRS - What is it?
VMWare DRS (Distributed Resource Scheduler)
Distributed Resource Scheduler or DRS is an add-on feature of VI 3 infrastructure that is managed by Virtual Center. DRS allow balancing the CPU and memory resources of the virtual machines or VMs and the other ESX servers in the cluster.
DRS helps to balance the CPU and memory of its cluster members based on the configured resource pool policies such as shares, reservations and limits. The hosts and VMs are continuously monitored by the virtual center. Based on the configuration, if there is any imbalance of resources, the VMs are moved across the hosts in the DRS cluster.
The placement of VMs across the cluster can be configured based on,
Affinity and anti-affinity rules – Rules that define which VMs can run together (affinity) and cannot run together(anti-affinity) in any given host. A perfect example for anti-affinity would be placement of a SQL server and Exchange server. At any point of time, you don’t want to place both the servers in the same host.
VMotion compatibility – VMotion has it’s own set of requirements to move the VMs across the hosts. For example, if a VM that has a local network (not connected to any physical adapter) cannot be moved using VMotion.
Based on the environment and needs DRS automation can be set to the following levels:
Manual – DRS only provides recommendation on placing the VMs. Manual action is required to place them on recommended hosts
Partially automated – During VM power-on, they will be placed on the DRS recommended hosts. VM migrations caused by resource imbalance will be recommended by DRS but won’t be moved automatically
Fully automated – DRS automatically places the VM during power-on also during resource imbalance on the DRS recommended hosts. The migration threshold level can also be set with this level between conservative and aggressive using a slide bar.
Few factors to consider about DRS:
There can be up to 32 hosts per DRS cluster
It’s recommended to use combination of DRS automation levels based on the critical nature of VMs. To accomplish this, the cluster level DRS automation can be overridden by the VM level automation setting.
In the manual and partial automation level, it is important to pay attention to the number of stars on the recommendation. A 5-star recommendation should always be considered and applied.
Swap file location for the VMs is configurable in the DRS cluster and it is recommended to keep the swap file in the same directory in the VMFS datastore for performance reasons. Choosing to keep the swap file of the VM in the datastore based on the host setting will result in a poor VMotion performance during a resource imbalance.
More details about DRS cluster can be found here:
www.vmware.com/pdf/vmware_drs_wp.pdf
http://pubs.vmware.com/vi301/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_concepts.6.6.html
Distributed Resource Scheduler or DRS is an add-on feature of VI 3 infrastructure that is managed by Virtual Center. DRS allow balancing the CPU and memory resources of the virtual machines or VMs and the other ESX servers in the cluster.
DRS helps to balance the CPU and memory of its cluster members based on the configured resource pool policies such as shares, reservations and limits. The hosts and VMs are continuously monitored by the virtual center. Based on the configuration, if there is any imbalance of resources, the VMs are moved across the hosts in the DRS cluster.
The placement of VMs across the cluster can be configured based on,
Affinity and anti-affinity rules – Rules that define which VMs can run together (affinity) and cannot run together(anti-affinity) in any given host. A perfect example for anti-affinity would be placement of a SQL server and Exchange server. At any point of time, you don’t want to place both the servers in the same host.
VMotion compatibility – VMotion has it’s own set of requirements to move the VMs across the hosts. For example, if a VM that has a local network (not connected to any physical adapter) cannot be moved using VMotion.
Based on the environment and needs DRS automation can be set to the following levels:
Manual – DRS only provides recommendation on placing the VMs. Manual action is required to place them on recommended hosts
Partially automated – During VM power-on, they will be placed on the DRS recommended hosts. VM migrations caused by resource imbalance will be recommended by DRS but won’t be moved automatically
Fully automated – DRS automatically places the VM during power-on also during resource imbalance on the DRS recommended hosts. The migration threshold level can also be set with this level between conservative and aggressive using a slide bar.
Few factors to consider about DRS:
There can be up to 32 hosts per DRS cluster
It’s recommended to use combination of DRS automation levels based on the critical nature of VMs. To accomplish this, the cluster level DRS automation can be overridden by the VM level automation setting.
In the manual and partial automation level, it is important to pay attention to the number of stars on the recommendation. A 5-star recommendation should always be considered and applied.
Swap file location for the VMs is configurable in the DRS cluster and it is recommended to keep the swap file in the same directory in the VMFS datastore for performance reasons. Choosing to keep the swap file of the VM in the datastore based on the host setting will result in a poor VMotion performance during a resource imbalance.
More details about DRS cluster can be found here:
www.vmware.com/pdf/vmware_drs_wp.pdf
http://pubs.vmware.com/vi301/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_concepts.6.6.html
Thursday, July 9, 2009
Cloud Computing- The future of computing? – Part I
Cloud Computing – A buzz word that is murmured everywhere by the IT folks or even non-IT people recently. This article describes what it really means to the beginners those who are interested or looking into cloud computing.
Cloud computing is a computing model where the infrastructure and the application (even the platform) is offered as a service over the Internet. The infrastructure cloud could include servers and storage and the application cloud includes various applications such as web and databases.
Even though cloud computing can be classified into many different types the major ones are Public clouds, Private clouds and Hybrid clouds.
Public clouds – As the name suggests, it is usually offered by a company who has invested a lot building their datacenter and offering a part of its infrastructure and platform for a monthly fee. Amazon, Terremark, RackSpace and Google are great examples of public clouds
Private clouds – This is something that enterprises build by themselves to be utilized across their organization. This allows them to consolidate their servers (and storage) as a single entity that can be offered to their different business units as needed. There is an interesting article from Network World can be found here.
Hybrid clouds – This is an emerging area of cloud computing where the private and public clouds can be integrated. There are many factors such as security and application compatibility needs to be considered in this model
Driving factors for cloud:
The recent developments in the virtualization technology gave a big boost to cloud computing. There are many reasons that drive the cloud computing. Some of them are,
Rapid deployment of servers and applications
Easier scalability
Allowing IT to run as a cost center by running multiple datacenters as single entity which can be shared and charged back based on usage
Cost efficient pay as you go pricing model
Apart from its benefits, there are still few concerns about the security, compliance and the application compatibility with cloud computing. However, they are being addressed by the cloud vendors.
Let’s look into some of the cloud services in-depth in Part II
Cloud computing is a computing model where the infrastructure and the application (even the platform) is offered as a service over the Internet. The infrastructure cloud could include servers and storage and the application cloud includes various applications such as web and databases.
Even though cloud computing can be classified into many different types the major ones are Public clouds, Private clouds and Hybrid clouds.
Public clouds – As the name suggests, it is usually offered by a company who has invested a lot building their datacenter and offering a part of its infrastructure and platform for a monthly fee. Amazon, Terremark, RackSpace and Google are great examples of public clouds
Private clouds – This is something that enterprises build by themselves to be utilized across their organization. This allows them to consolidate their servers (and storage) as a single entity that can be offered to their different business units as needed. There is an interesting article from Network World can be found here.
Hybrid clouds – This is an emerging area of cloud computing where the private and public clouds can be integrated. There are many factors such as security and application compatibility needs to be considered in this model
Driving factors for cloud:
The recent developments in the virtualization technology gave a big boost to cloud computing. There are many reasons that drive the cloud computing. Some of them are,
Rapid deployment of servers and applications
Easier scalability
Allowing IT to run as a cost center by running multiple datacenters as single entity which can be shared and charged back based on usage
Cost efficient pay as you go pricing model
Apart from its benefits, there are still few concerns about the security, compliance and the application compatibility with cloud computing. However, they are being addressed by the cloud vendors.
Let’s look into some of the cloud services in-depth in Part II
Friday, June 26, 2009
Exporting Windows Event Viewer data for compliance
Exporting Windows Event Viewer data for compliance
The companies that are subjected to regulatory compliance are often required to store and archive the logs from various part of their infrastructure such as applications, firewalls, VPN and servers. Most of the network devices support Syslog and if you have any syslog server in your environment you should be able to view, collect and archive the syslog data. Kiwi Syslog server is one of the best tools available in the market.
Windows servers do not have a syslog client by default and usually all the system related warnings, alerts and information are stored and displayed in the Windows Event Viewer. Event viewer allows exporting of data locally in different formats for review. However, in an enterprise environment, there is no tool exists to automate the collection of event viewer from a centralized location.
One great solution for this is using software called ‘winlogd’. Winlogd converts the windows event viewer logs into syslog and send it to the syslog server. Winlogd installs itself as a windows service and requires a registry edit to specify the syslog server IP.
It can be easily pushed to all the servers in an enterprise environment using a .reg file.
Once the syslog server can receive the data from servers, it can be viewed and archived for compliance purposes.
One limitation of Winlogd is it doesn’t allow filtering the window event viewer logs. So, all the data that is going to Windows Event Viewer (including ‘information’) will be sent to syslog server. If you have many chatty servers that would cause lot of informational event logs, it may generate tons of syslog data and network traffic. I’m hoping that winlogd community will fix this in their next release. Nevertheless winlogd is a great tool!
More information on ‘winlogd’ can be found here:
http://edoceo.com/creo/winlogd
The companies that are subjected to regulatory compliance are often required to store and archive the logs from various part of their infrastructure such as applications, firewalls, VPN and servers. Most of the network devices support Syslog and if you have any syslog server in your environment you should be able to view, collect and archive the syslog data. Kiwi Syslog server is one of the best tools available in the market.
Windows servers do not have a syslog client by default and usually all the system related warnings, alerts and information are stored and displayed in the Windows Event Viewer. Event viewer allows exporting of data locally in different formats for review. However, in an enterprise environment, there is no tool exists to automate the collection of event viewer from a centralized location.
One great solution for this is using software called ‘winlogd’. Winlogd converts the windows event viewer logs into syslog and send it to the syslog server. Winlogd installs itself as a windows service and requires a registry edit to specify the syslog server IP.
It can be easily pushed to all the servers in an enterprise environment using a .reg file.
Once the syslog server can receive the data from servers, it can be viewed and archived for compliance purposes.
One limitation of Winlogd is it doesn’t allow filtering the window event viewer logs. So, all the data that is going to Windows Event Viewer (including ‘information’) will be sent to syslog server. If you have many chatty servers that would cause lot of informational event logs, it may generate tons of syslog data and network traffic. I’m hoping that winlogd community will fix this in their next release. Nevertheless winlogd is a great tool!
More information on ‘winlogd’ can be found here:
http://edoceo.com/creo/winlogd
Friday, June 19, 2009
Why does IP address and subnet mask matter in an enterprise network?
Why does the IP address and subnet mask matter?
We had an interesting issue that relates to networking and SQL heartbeat with one of our clients that I would like to share.
One of our clients has their servers distributed across 3 data centers in US. Let us call them A, B and C. They have a VPN tunnel connecting all their sites together using Cisco ASA firewalls. Their IT staff access the entire infrastructure through one data center (A) which has remote access VPN enabled in the Cisco ASA. They recently reported an issue of not being able to access the servers in SQL cluster across remote access VPN located in data center (B). However, those servers are accessible from data center A, C and within B itself and others servers in data center B were accessible through remote access VPN.
As their remote VPN connection terminates at Cisco ASA at data center (A), various teams were involved to find out the cause. The following were checked to identify the cause of this issue:
It was ensured that the remote access VPN subnet (10.1.1.x) is added to the crypto-map on the site to site VPN configuration.
We also made sure all the servers are connected to the same switch and residing on same VLAN.
There was no specific access list (ACL) or firewall or IPS or F5 configuration that was blocking traffic to the database servers from remote access VPN subnet (10.1.1.x).
We ensured all the servers have the same IP default gateway configured.
During packet tracing, it is found that the traffic reaches to the ASA at data center A and also reaches data center B. It is found that the traffic was not going back from the servers to the remote access VPN subnet. We realized that there would be something wrong on the SQL cluster servers and started looking in depth on its network configuration. We identified that SQL server’s heart beat NIC was configured with the IP address of 10.0.0.x with a subnet mask of 255.0.0.0 (/8) allowing to have 16777214 hosts where only 2 IP addresses are needed for heart beat. So, all the incoming traffic from remote access VPN was forwarded to the heart beat NIC on the SQL servers and not going back to the remote access VPN ASA.
Having a subnet mask of 255.255.255.252 on SQL servers heart beat network would have allowed it to have only two IP addresses that are needed for heartbeat on the SQL cluster. As it is a production SQL network, we did not want to change the heart beat network’s IP address or subnet mask. As an alternative workaround, we used persistent route in Windows 2003 to configure the remote access VPN traffic to reach the correct NIC and gateway. A helpful article on windows 2003 routing can be found here. Once we added the persistent route, the remote access VPN users were able to access the SQL servers.
Lesson’s learned:
Make sure you aware of all the network addresses and subnets involved in all the locations.
Assign a subnet mask for the required number of host addresses.
We had an interesting issue that relates to networking and SQL heartbeat with one of our clients that I would like to share.
One of our clients has their servers distributed across 3 data centers in US. Let us call them A, B and C. They have a VPN tunnel connecting all their sites together using Cisco ASA firewalls. Their IT staff access the entire infrastructure through one data center (A) which has remote access VPN enabled in the Cisco ASA. They recently reported an issue of not being able to access the servers in SQL cluster across remote access VPN located in data center (B). However, those servers are accessible from data center A, C and within B itself and others servers in data center B were accessible through remote access VPN.
As their remote VPN connection terminates at Cisco ASA at data center (A), various teams were involved to find out the cause. The following were checked to identify the cause of this issue:
It was ensured that the remote access VPN subnet (10.1.1.x) is added to the crypto-map on the site to site VPN configuration.
We also made sure all the servers are connected to the same switch and residing on same VLAN.
There was no specific access list (ACL) or firewall or IPS or F5 configuration that was blocking traffic to the database servers from remote access VPN subnet (10.1.1.x).
We ensured all the servers have the same IP default gateway configured.
During packet tracing, it is found that the traffic reaches to the ASA at data center A and also reaches data center B. It is found that the traffic was not going back from the servers to the remote access VPN subnet. We realized that there would be something wrong on the SQL cluster servers and started looking in depth on its network configuration. We identified that SQL server’s heart beat NIC was configured with the IP address of 10.0.0.x with a subnet mask of 255.0.0.0 (/8) allowing to have 16777214 hosts where only 2 IP addresses are needed for heart beat. So, all the incoming traffic from remote access VPN was forwarded to the heart beat NIC on the SQL servers and not going back to the remote access VPN ASA.
Having a subnet mask of 255.255.255.252 on SQL servers heart beat network would have allowed it to have only two IP addresses that are needed for heartbeat on the SQL cluster. As it is a production SQL network, we did not want to change the heart beat network’s IP address or subnet mask. As an alternative workaround, we used persistent route in Windows 2003 to configure the remote access VPN traffic to reach the correct NIC and gateway. A helpful article on windows 2003 routing can be found here. Once we added the persistent route, the remote access VPN users were able to access the SQL servers.
Lesson’s learned:
Make sure you aware of all the network addresses and subnets involved in all the locations.
Assign a subnet mask for the required number of host addresses.
Subscribe to:
Posts (Atom)
Posts
