Veeam Community Forums Digest for dandvo [Oct 2

Veeam Community Forums Digest for dandvo [Oct 2 - Oct 8, 2017]

Veeam Community Forums Digest

October 2 - October 8, 2017

THE WORD FROM GOSTEV

Last week, we have released the new version 1.5 of Veeam Backup for Microsoft Office 365. While a dot release, it brings significant scalability improvements by introducing the distributed architecture to support largest Office 365 deployments, as well as to enable service providers to provide the necessary physical isolation to support protection of multiple tenants. Other notable improvements include expanded support for source environments, with an addition of on-prem and hybrid Exchange deployments, as well as China and Germany Office 365 regions. Plus there are many performance and other enhancements of course, see the detailed information here > What's New in 1.5. There's also one important reliability fix around Office 365 organization tracking: v1 used the org identifier GUID, which as we found out recently may sometimes change due to the internal Office 365 process called Tenant Relocation. What this effectively means is that tenants is migrated to different parts of the O365 infrastructure, for example for load balancing reasons. This process is transparent to the end user but causes VBO365 1.0 jobs to start failing, and version 1.5 fixes this by using the Identity org parameter instead – so I highly recommend upgrading even for this fix alone. Here are the direct links to the Release Notes and the actual bits for your convenience.

Here's one other Microsoft Ignite finding that I didn't have enough time to cover last week, especially since this question came up on the forums a few days ago – but we had many of our partners reaching out for clarifications even before that. Basically, most recently Microsoft has updated their ReFS documentation by adding a note stating nothing less than "ReFS is not supported on SAN-attached storage". This made no sense to me, because both unsupported SAN LUN and fully supported basic disks are absolutely identical block devices from a file system perspective, so I was looking for some additional information at Ignite - and was lucky enough to run into the exact person behind this note – so I got clarifications directly from the source. The technical reason behind this note appears to be the fact that Microsoft Support have seen some SAN storage devices which do not honor the flush command, which is extensively used by file systems and apps to guarantee that the data has landed to the disk and is consistent. So this is not really a ReFS-specific issue – if you saw my Backup Repository Best Practices VeeamON presentation, you know those "questionable performance optimizations" of RAID controllers on some low end SAN storage which delay or simply ignore flush commands is the reason Veeam also does not support such storage as backup targets. But from Microsoft perspective, they cannot possibly test every RAID controller out there, so they opted for such a blanket statement. Meaning there's nothing to worry about for those using proven enterprise-grade storage, while those with consumer-grade devices should probably consider enabling pass-through RAID controller mode regardless of the file system behind the repository, so that all I/O goes straight to the disks.

For VMware users – here's a nice article that explains and shows the difference between various VMware disk types using a simple yet genius test > Thin vs. Eager thick vs. Lazy thick disk performance

For NetApp users – I was struck by some numbers NetApp is promising for the upcoming ONTAP 9.3 release, so I thought this was worth sharing here because of how many NetApp users we have as our customers (and this number will probably grow much quicker now that NetApp customers can purchase joint solution directly from NetApp and its resellers). Basically, NetApp promises 40% performance improvement over prior ONTAP versions by using path parallelization to deliver more IOPS with lower latency. This is pretty awesome if true – who does not want to bump the performance of their existing systems by 40%? We have some FAS systems in our dev labs and we will take that any time! And another big improvement with ONTAP 9.3 is 30% capacity savings Increase through inline deduplication, compression and compaction processes – however, this sounds like something specific to their ONTAP-based all-flash arrays only (and I'm not really sure how big are those these days in light of awesome SolidFire all-flash arrays being a part of NetApp portfolio for 2 years now).

For Mac users – be aware of this embarrassing bug in freshly released macOS High Sierra > macOS High Sierra may show the actual password instead of the password hint

VEEAM CLOUD & SERVICE PROVIDER CORNER

It still me Gostev manning this section today - and I just wanted to expand a little on the new Veeam Backup for Microsoft Office 365 release from the service provider perspective. As I already noted, multi-tenancy was a big feature of this release as we wanted to enable our MSPs to use this solution to backup their client's Office 365 mailboxes. However, one challenge with backups stored in the service provider's data center (as opposed to the tenant's own environment) is that self-service restores become impossible... but not with Veeam! One cool feature that is not mentioned in the What's New document (because it requires yet to be released Update 3 for Veeam Backup & Replication 9.5) is the ability for tenants to perform self-service restore directly from Office 365 backups located in their managed service provider's repository through the Veeam Cloud Connect tunnel. Yep, this is yet another use case for our most awesome VCC technology for you to enjoy! Now, your tenants can fire up Veeam Explorer for Exchange in their environment normally, and connect directly to their Office 365 backup repository in your environment. As you can see, we keep delivering on our promise that your investment into Veeam Cloud Connect infrastructure will keep paying off!

BEST POST OF THE WEEK

Re: Integration with Storage Snapshots : Vendor Roadmap [BY: @AndyandtheVMs Veeam PM • LIKED: 3 times]

Hello Customers and Partners, thank you for all your feedback and voting. We really appreciate that you actively interact with us and I can assure you that the forum and this forum thread has a powerful voice within our decision processes.

As Anton Gostev already announced in his forum digest, we will prepone some exiting features from v10 to v9.5 Update 3 and you guys here will love it. We will share some additional news soon. And please monitor the public announcements in the next half year for even more news.

Overall the storage vendor selection process has not changed. In the past Veeam did all the vendor integrations ourselves which lead to a single storage vendor integration per year. With the upcoming release of the new Veeam Universal Storage API, we had built a joint development process that can accelerate the number of vendor per year 5 times and more. With the API we will keep the deep integration and easy to use interface that is used today. When the API is released as a part of Update 3, you will see many news around it on a more regular base.

There is no beta program for the API. Veeam developers had built one other integration based on the API ourselves (IBM SVC) to polish the process from vendor perspective. Plus, another storage vendor was chosen to work on the pilot process with us and trust me, this vendor had a hard life to keep up with all of our changes. The good thing why we went that path is, that the integration process is solid right from the release of the first API version. Next 2 vendors are already in the queue and waiting for our final API release.

Beside your voting here, the selection process looks on our joint revenue and pipeline. So those vendors that work actively with us and our partners, have better chance to get selected by our top management. Likely this will match with our install base, but we monitor upstart vendors as well. So you will see that we will not look at the public market share alone as the main indicator. So over time, our top management will keep picking additional storage vendors for the Universal Storage API program, based on the load of our QA team and progress of already selected vendors.

As we had announced the API program a long time ago, we already have a huge list of storage vendor candidates that want to work with us (nearly all of the storage vendors). It is sometimes frustrating for them and us to wait for the API release and to be selected within the top management decision process. I am sorry about this, but you all can be sure that we will treat this serious in the best interest of our customers and will accelerate after the actual API release.

You can see on the latest integrations and announcements that we had already started to accelerate the vendor integrations: This year with the releases of Nimble and Cisco HyperFlex ... plus the Veeam Public announcements of IBM/Lenovo/Infinidat/Pure integration that will come soon. You will also see additional updates of the existing integrations in the same timeframe.

If you have any questions, you can contact me at andreas.neufert (at) veeam.com
I work for our Product Management within the Global Alliance team and take care about all 3rd party vendor integrations.

ddprecist

Prohledat tento blog

Veeam Community Forums Digest for dandvo [Oct 2 - Oct 8, 2017]

Komentáře

Okomentovat