I’ve started to play around with the idea of Orchestration and Automation a bit more in the past few weeks. The recent Melbourne VMUG rekindled my interest in the area once again so I’m trying to find the time to play around with a few different applications and see what fits. One of the most versatile and capable products out there for VMware orchestration is VMware vCenter Orchestrator (now called vRealize Orchestrator) and the fact that it’s free with your vCenter server license means there’s really little to no excuse for not learning the product and adding another skill to your virtualization armour.
You can download vCenter Orchestrator appliance from the myVMware website. You’ll need a VMware login to get access to download. Make sure to download the OVA file as it just makes deployment easier. Once you have have downloaded the OVA, you can then deploy the template.
Browse to your downloaded OVA file and once selected click Next.
A recent comment highlighted that i was missing a step during Step 8: UPGRADE THE FABRIC INTERCONNECTS AND I/O MODULES. This was to manually change the primary status for the Fabric Interconnects to be the recently upgraded Fabric Interconnect. This way your environment remains accessible while the second FI is being upgraded. I’ve updated this step now to include the manual failover steps on the FI. It is a step I always follow when performing upgrades but I can’t think of why I didn’t originally put it into the post.
Recently I was tasked with performing an upgrade to our UCS environment to support some new B200 M4 blades. The current firmware version only supported the B200 M3 blades. As part of the process I performed the below steps to complete the upgrade. I split the upgrade into a planning phase and an implementation/upgrade phase. Upgrading firmware of any system can lead to potential outages, things have definitely improved on this over the past decade, but it’s imperative that you plan correctly to make the implementation process go without any hitches. With UCS firmware there is a specific order to follow during the upgrade process. The order to follow is:
- Upgrade UCS Manager
- Upgrade Fabric Interconnect B (subordinate) & Fabric B I/O modules
- Upgrade Fabric Interconnect A (primary) & Fabric A I/O modules
- Upgrade Blade firmware by placing each ESXi Host
During the upgrade process, and particularly during the Fabric Interconnect and I/O module upgrades you will see a swarm of alerts coming from UCSM. This is expected as some of the links will be unavailable as part of the upgrade process so wait until all the steps have been completed before raising an issue with support. As a caveat however, if there is anything that really stands out as not being right open a call with support and get it fixed before proceeding to the next step. During my upgrade process some of the blades showed critical alerts that did not clear and the blades needed to be decommissioned and re-acknowledged to resolve it. This problem stood out and wasn’t hard to recognise that it was more serious that the other alerts.
You will need to check the release requirements from Cisco regarding the upgrade path from your current firmware version to the desired version and also the capabilities that the desired firmware version contains. The upgrade process takes some time so it’s best to review everything in advance and not have to do this on the day of the upgrade itself. For instance during this upgrade process I needed to ensure capability to support B200 M4 blades and VIC 1340 modules as they had been purchased as part of an order for a new project. The steps to carry out in the planning phase are:
Step 1: Verify the Upgrade requirements
Check the release version notes on Cisco’s website for the version you want to upgrade to. For this example we are upgrading to version 2.2
As part of some recent evaluation work I did on vRealize Operations Manager and following a discussion with our VMware rep I installed vRealize Log Insight. It’s a product I’ve heard about before, largely in conjunction with EVO:RAIL as its part of the automatic deployment, but not a product that I’ve really seen a need for. As part of the vRealize Suite it links nicely into vROps so I thought why not give it a chance and see what it can do. So far I’ve been impressed. I’ve only configured it to monitor my VMware environment but it is also possible to get data from devices outside on the virtual platform. For want of a better example you can see Log Insight as a syslog server or a Splunk Server. There may be other ways of installing vRealize Log Insight Manager but below are the steps I followed to get the platform off the ground and it follows the similar steps to my earlier How-To: VMware vRealize Operations Manager Installation guide
Go to VMware vRealize Log Insight web page and download the vRealize Log Insight OVA file. You will need a VMware account for this and you will also get a 60-day trial license key. You can also check out the VMware vRealize Log Insight Getting Started Guide and the vRealize Log Insight Administration Guide for more information of what to do within Log Insight. Once you have downloaded the appliance you can go into vCenter and select Deploy from OVF Template.
Browse to the downloaded OVA file, select and click Open
Step 3: Read More
I’ve recently being playing around with the vRealize Suite as part of on-going evaluations into various management tools. Today I’m going to cover the installation process for vRealize Operations Manager. There have been a number of improvements in the latest version of Operations Manager. It was not just a name change from vCOPS to vROps as part of the latest release, there have been a number of great features added and I think VMware have finally put the effort into making their management suite of products work cohesively. I’m not going to go into the ream of features and updates to vRealize Operations Manager as others have done a far better job at that than I can but I can provide a step by step installation guide.
Go to VMware vRealize site and download a trial version of vROps. You will require a VMware account to do this and agree to any licensing. You can download the OVA file for vROps to your local computer. Once you have downloaded the appliance you can go into vCenter and select Deploy from OVF Template
Select the OVA file just downloaded and click Next
Over the weekend I had to run a failover test for an application within SRM. As SRM can only replicate down to the datastore level and not the VM level this meant doing a full test failover of all VMs but ensuring beforehand that all protected VMs in the Protection Group were set to Isolated Network on the recovery site. This ensure that even though all VMs would be started in the recovery site they would not be accessible on the network and therefore not cause any conflicts. The main concern, outside of a VM not connecting to the isolated network, was that the VM being tested and the application that sits on it are running on Windows 2000. Yes, that’s not a typo the server is running Windows 2000. The application is from back around that period as well so if it drops and can’t be recovered then it’s a massive headache.
Step 1: Power down the production VM
Step 2: Perform Test Recovery
Go to Recovery Plans -> Protection Groups and select Test
When the prompt comes to begin the test verify the direction of the recovery, from the protected site to the recovery site. Enable the Replicate recent changes to recovery site. In most cases you will be already running synchronous writes between the sites and the data will just about be up to date anyway. It is recommended however to perform a recent change replication anyway to make sure that all data is up to date.
Click Next and then click Start to confirm the test recovery
While working on a recent project for a client utilising Cisco UCS and NetApp for a cloud offering I was tasked with getting Trend Deep Security 9 working for a multi-tenant cloud environment. The primary caveat is that the environment isn’t true end-to-end multi-tenancy as the virtualisation layer is not fully segregated. vCloud Director or another similar tool has not been used but rather the vCloud Suite from VMware and segregation is at the network and storage layers through the use of vDCs on Nexus 7k (network) and SVMs on NetApp Clustered Data OnTap (storage virtual machines). In the production environment Trend Micro professional services were engaged to deliver the original design. Part of the criteria given to them was not to enable multi-tenant mode within the Shared Resources cluster as the tenants would not be managing their own anti-virus protection or scanning. In order to satisfy the requirements of multiple VMware clusters protected by one Anti-virus package a DSM was deployed on each cluster and managed from a central console within the Management cluster. I will go into more of a discussion on the ideal architectural design for multi-tenant anti-virus in another posting.
And so to the beginning of the troubles. No anti-virus solution is really ever straight-forward. There’s a number of policies and exclusions to consider for both operating systems and specific applications and usually there is lack of distinct information within the installation and admin guides. Trend Micro Deep Security Manager is no different. This however is not a huge criticism of Trend, they have to make their documentation as generic as possible for multiple use cases. It does make installation just that bit more frustrating though. You can find the full Deep Security 9.0 Installation Guide here.
Trend Micro Deep Security consists of a number of components that work together to provide protection against viruses and malware in real-time. It can also provide Intrusion Prevention, Web Reputation, Firewalling, File Integrity Monitoring and Log Inspection. It is also available as both agent-based and agentless options. The component of Trend Deep Security are:
- Deep Security Management Console (DSM) – this server (recommended to be virtualised) is the central web-based management console for controlling and managing all Deep Security enforcement components (DSA’s and DSVA’s). The Server is recommended to be Windows Server 2008/2012 R2 64bit.. It is important that it is installed on a different ESXi host to that hosting the VM’s which are protected by the DSM. The DSM should be allocated 8GB and have 4 vCPU allocated. This configuration will be capable of serving up to 10000 agents. The MS SQL database size is relatively small at around 20GB for 10,000 agents.
- Deep Security Relay (DSR) – this server is responsible for contacting Trend Micro’s Security Centre for collection of platform and security updates and relaying this consolidated information back to the DSM and to Agents and Virtual Appliances. The DSR will also be virtualised at Interactive with 8GB ram and 4 vCPU. This configuration will be capable of serving up to 10,000 agents. The Relay has an embedded Agent to provide local protection on the host machine. In the case of multiple relays each will act independently and synchronise their local databases with the Trend Security Centre.
- Deep Security Virtual Appliance (DSVA) – this server is a virtual machine appliance that is installed on every ESXi host. The DSVA enables agentless Deep Security control and management within the hypervisor, providing Anti-Malware, Intrusion Prevention, Integrity Monitoring, Firewall, Web Application Protection and Application Control protection to each VM. The agentless control is only currently available for vSphere 5.1 or earlier. Support for VMware 5.5 will be available in 2014 Q2. The DSVA will communicate directly with the DSM and it is recommended to enable affinity rules within VMware to lock each DSVA to their required ESXi host.
- Deep Security Agent – for non-Windows servers (such as Linux), the agent is deployed directly to the VM’s OS computer, providing Intrusion Prevention, Firewall, Web Application Protection, Application Control, Integrity Monitoring and Log Inspection protection. This is the traditional client-server deployment model and the agent could be included within the imaging process or pushed out from the DSM. DSA will also be necessary on all VM’s within a vSphere 5.5 hypervisor until Q2 2014 (after which a DSVA can be used with vSphere 5.5).
- Smart Protection Server. Web reputation works by clients contacting Trend Micro’s Smart Protection Service on the Internet. Rather than all clients accessing this service, it is possible to deploy Trend Micro’s Smart Protection Server as a VM. The Smart Protection Server will periodically update its URL list allowing it to locally respond to client requests for web reputation ratings. This component is normally part of the Trend Micro Office Scan products and using it may incur an additional licensing fee. Given that the DSVA also caches similar data, this product is not recommended. Hence, the DSVA and DSA will regularly be checking web reputation over the Internet.
- Deep Security Notifier – is aWindows System Tray application that communicates the state of the Deep Security Agent and Deep Security Relay on local computers. A DSA and DSR already contain the Notifier but for Windows guests protected by the DSVA will need ti install the Notifier as a standalone application.