Home

vSphere 6.5 with Intel X710 network adapter

User Rating: 0 / 5

Details: Published: Wednesday, 28 March 2018 09:04

In the past I was really impressed by Intel's product stability and support. You could take every single hardware from Intel, put it into your server and all applications and operating systems supported them instantly. Driver support was excellent so no reason to think about sometimes instable chipsets from QLogic, NetXen, Emulex or even Broadcom. With the release of the X710 chipset this success story should continue. Don't ask my why but I had my first Intel X710 NIC installed in a new hardware used for vSphere 6.5 these days. I installed ESXi 6.5 and as expected, the hardware was correctly recognized.

After base configuration of two of these ESXi hosts I connected them to vCenter. The first one could be attached successfully, the second one was unable to connect. I double checked all settings like ip address, VLAN, password etc. The system was even pingable. The error from vCenter directed to not running management agents on the ESXi hosts. Well, this was a brand new installation and I never had to restart the host or the management agents before I can attach the host to vCenter. Nevertheless, I restarted the management agents and, voila, the second ESX host connected to vCenter.

In the next few minutes I configured host 2 to macth my standard. Suddently host 1 disconnected from vCenter. The system was still pingable but reconnect didn't work. Restarting the management agent did the job once again. During the day no more disconnets were observed so I didn't crawl any deeper into this problem. The weekend came and on monday the customer told me that all of his VMs were in suspend mode and both ESXi were disconnected from vCenter. Sh.....!

Once again checking and restarting the management agents causes both ESXi to reconnect. Vms were shutdown because of an HA isolation event. Nothing special here, this is the default setting for host isolation response.

Fujitsu StorageCluster Walkthrough part 2

User Rating: 5 / 5

Details: Published: Tuesday, 27 March 2018 11:36

Welcome back to part 2 of my ETERNUS StorageCluster Walkthrough. Part 1 covered some basic topics. Part 2 will be a technical part where I wil show you how to implement the solution.
For better understanding I will do that in a kind of step-by-step guide but not in very great detail. SC isn't extremely easy and you should have a solid understanding of base technologies in the ETERNUS storage systems. So please don't try to implement SC as a complete newbie.

Let's start....

Step 1: software installation

The software installation is quite simple. If you already have ETERNUS storage systems you probably have SF Cruiser already installed. The installation itself is always the same no matter if you have Express, Basic or Standard Edition of SF Cruiser. Simply take a Windows Server host (2008R2 or higher, I would recommend using Server 2012 R2 or 2016), join it to an AD (or leave it standalone, it's only important for the accounts you can use to logon to the application), put in the installation media (you can get latest version from http://www.fujitsu.com/global/support/products/computing/storage/download/esf-mediapack-trial.html) and start the installation. Take care about the groups that must exist on the system for authentication reasons.
After setup is done, connect to SF Cruiser (https://name-of-your-sf-server:9855), login with administrative credentials (see group membership) and start adding your ETERNUS systems

Fujitsu StorageCluster Walkthrough Part 1

User Rating: 0 / 5

Details: Published: Tuesday, 27 March 2018 08:30

Fujitsu's StorageCluster feature is a very interesting piece of technology. Not only because it offer synchronous mirroring with transparent failover in a native way without the need for additional software like DataCore's SANsymphony, IBMs SVC or FalconStors NSS but rather because it is very versatile. You can mirror between every ETERNUS DX system as long as it is generation S3 or higher and runs firmware V10L20 or higher. For example, you can mirror between a DX100 S4 on the first site and a DX600 S3 on the second site. This is possible because all ETERNUS DX systems share the same firmware and only the hardware it runs on is more ore less powerful. This is a real hardware invest protection. The second very interesting feature is the lack of capcity based licensing. Synchronous mirroring (Fujitsu calls it StorageCluster) is licensed on system level, so once you bought the license it doesn't matter how much storage you put into your system. This is a very important fact in times where capacity grows more and more.

Although the StorageCluster is a nice feature especially in the DACH or EMEA region (we love synchronous mirroring) there is pretty few information about it on the internet. If you ever think about implementing this feature you shouldn't rely on community posts, blog articles or even a documentation from Fujitsu themselfes. Don't ask me why but there is not even an official documentation for this feature on the web as far as I know. You can find some information about SC in some whitepapers and some presentations but a dedicated walkthrough paper you probably won't find. Perhaps the reason is because the product is not that popular and Fujitsu is definetly not that common as systems from HPE or Dell/EMC but I'm pretty sure that is is not because the products are bad. Absolutely not, FTS's storage products are very stable, perhaps not that feature rich, but absolutely reliable, easy to setup and maintain (most of them :-) ) and very flexible.

Back in business

User Rating: 0 / 5

Details: Published: Thursday, 22 March 2018 12:14

Hi everybody, I just want to inform the internet that v-strange.de will be back in business in the next few days.

I do this blog mainly in my free time and the last few years my family had absolute priority so please forgive me neglecting my blog in this time. As kids grew up the free time will hopefully a bit more and I have more time to do writing down my experience with new technologies and describe problems I stumbled across. I got great feedback during the first years of this blog and I'm convinced that my information provided help to a significant amount of readers so I'm very motivated to publish new articles.

In the meantime my focus changed a bit, so DataProtector for example isn't a focus anymore. Don't get me wrong, DP is still a good product for special cases but for the majority of customers, DP is too "old-school" and complicated in comparision to products like Veeam. Most of my customers changed to Veeam with only three customers still using DP. This is a significant reduction and because of this, I will probably drop DP from my blog. If you are still interested in news about DP send me a comment.

Simplivity and CloudByte will also be dropped. Simplivity just because there are solutions on the market that are nearly as good as Simplivity but much cheaper and more flexible and I want focus on open and flexible solutions like VMware vSAN, Microsoft Storage Spaces Direct or DataCore's HCI solution.

CloudByte was a newcomer on the market and we got great expectations on this technology as it could become a real alternative to NAS systems like the ones from NetApp or to be an opponent to disk based backup solutions like EMCs DataDomain or HPEs StoreOnce. Unfortunately it felt short on our expectations and especially in the dedup area and usage as a backup appliance it was way behind our requirements. So still it will have some use cases but not that much to be a focus technology for me or my company.

One more key focus will be introduced on this blog: Fujitsu server and storage systems. As a former HPE-only company we spent a lot of time implementing HPE systems at customer site not looking left and right for other vendors. As HPEs strategy regarding partners and product portfolio went a bit confusing, we started to give another player a chance. That was Fujitsu and we are really pleased with them in the meanwhile. Very good product portfolio (not that big as HPE but more streamlined and continuously and "designed and made by FTS" (in opposite to HPE that is continuously buying 3rd party companies)) and very good partner support. Both things are mandatory if you want to be successful in the on-prem market. Switching to new technology and vendors is always a challenge but FTS supported us very well and today we have a strong knowledge in the main areas. Several successful projects are already implemented with new ones come in nearly every day.

To cut a long story short: v-strange.de is back in business! Have fun!

Veeam v9 and vSphere 6 - no VSS extension upload using VIX

User Rating: 0 / 5

Details: Published: Thursday, 23 June 2016 16:03

A few days ago I was at a customer that uses Veeam to backup his vSphere environment. Nothing special in the configuration. We run this setup for a few years now and it was bulletproof.

Recently we upgraded to Veeam v9 and vSphere 6 to be on the latest major versions both vendors offer. Since then we have a strange problem that was overseen for a while.

The customers security requirements deny access for any system from the internal network to the DMZ, especially for the backup server. To have fully consistent backups of VMs running in the DMZ we use Veeam VAAIP agents uploaded to the VMs via VIX because RPC (admin share access via CIFS) is not allowed. This worked perfectly even with Veeam v9 and vSphere 6. Perfectly until the customer upgraded the VMware Tools on his DMZ VMs. The weeks before the problem arose the VMs ran on vSphere 6 but with VMware Tools from 5.5. The moment he upgraded to VMware Tools 10.x the VIX upload didn't work anymore. The problem only hits a few VMs that can not leverage RPC as alternative upload method.

VMXNET3 compatibility problem

User Rating: 0 / 5

Details: Published: Monday, 06 June 2016 08:23

Microsoft released convenient rollup update for Windows 7 and Server 2008 R2 in late May 2016. This rollup update will bring your installation to the latest patch level with only a few installations but it has a bad side effect. All VMs running on vSphere (it seems that ALL vSphere versions are affected) and use the VMware proprietary VMXNet3 type of virtual network card will prbably being hit by network issues. The reason behind this is that after applying the update, the OS will create a new vNIC but the settings for the old vNIC will still reside in the registry. This will lead to network problems.

You can get some more details on the link above or here. VMware currently recommends to delay installation of this rollup package until there is a resolution from Microsoft.

vSphere 6 - critical VMXNET3 bug

User Rating: 0 / 5

Details: Published: Tuesday, 26 April 2016 16:32

With vSphere 6 update 2 VMware fixed several bugs but also introduced a new one. Update 2 includes a critical bug in the VMXNET3 vNIC that can produce PSODs (purple screen of death). The problems occur if:

the VM is running virtual hardware version 11
the VM is configured with VMXNET3 virtual nic
Large Receive Offload (LRO) for VMXNET3 NICs is enabled

Currently there is no resolution but a workaround. All details are published in KB2144968.

Fun with latest HPE SmartArray controllers

User Rating: 0 / 5

Details: Published: Wednesday, 20 April 2016 13:09

With latest Gen9 systems HPE published the new Generation of SmartArray controllers. These x4x controllers like P440, P441 or P841 are the fastest, most feature-rich and most flexible SmartArray controllers ever. With an impressive maximum performance of up to 1 million IOPs and a maximum number of up to 200 disks (P441) these controllers are pretty well suited for Software Defined Storage systems or any other DAS-related solution.

I, personally, use these controllers in DataCore environments where performance and scalability is a key factor and where flash devices are pretty common. Most older RAID controllers are not suited very well for SSD or flash generally spoken since they produce a bottleneck with their CPU or general bandwidth or, most often seen, they simply can't handle flash traffic very well.

The x4x controller series is developed to be used in conjunction with flash so these bottlenecks and limitations should be a matter of the past.

With this knowledge in mind I was pretty surprised during my last DataCore projects seeing some massive performance drops in the I/O backend sometimes. These drops were that strong that the complete I/O stopped during a period between 2 and 20sec. Fortunately most of these drops encountered during the DataCore pool initialization when there was no other I/O on the system except the initialization traffic itself. For explanation, during pool initialization the DataCore software simply writes zeros on the disks to prepare them to be used within DataCore. This is a 100% sequentiel IO stream without any special requirements. It simply writes zeros. So it was pretty clear that nothing could produce these drops except the controller itself.