If any one is getting slow backup performance either - you are not using it right - a NAS is not right for your workflow
We are able to archive 50+TB of source data that is written to both onsite and offsite tape per day. We have a method of scaling that further but that is sufficient for us at the moment. Our biggest bottleneck is the TSM database, not how fast we can get the data off the storage. Slight corrections - "each client can only talk to one isilon node PER MOUNT" - NFS and isilon are not slow nor are they sequential - It is the lack of scalable multithreading in the TSM agent that makes it slow and cumbersome, not isilon nor NFS - It is the lack of snapshot/snapdiff aware backups in the TSM agent that make complete back ups happen in an "inefficient way" - Isilon is a scalable NAS that can be very fast. Being a NAS it has restrictions in the latencies of TCP networking. If your after storage that is faster than what Network speeds/throughputs can provide you should be looking at other storage solutions. If anyone would like further clarification on these points, only happy to help give you more information or experience Grant ________________________________________ From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> on behalf of Frank Kraemer <kraem...@de.ibm.com> Sent: Friday, 7 September 2018 7:50 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] nfstimeout on server ISILON storage Isilon = Slow Performance - Although a parallel filesystem inside (OneFS), each client node can only talk to a single Isilon node using standard NAS protocols, which then performs parallel I/O across the internal high speed IB network to other Storage Nodes. - NFS Client nodes (=TSM Server) have to use slow non-parallel data access over Ethernet to the Isilon. NFS v3 is technology from 1986 - designed with networks in mind of that time!!!! - No direct client IB or high-speed network I/O with RDMA enabled to support so single client performance is poor in comparison to other real filesystems that scale. - Multiple NFS mounts from the same client (TSM Server) to the Isilon box can help a little but the setup is clumsy and this is not real parallel I/O - it's a hack! Still slow. - "Magic tools" like dsmisi from (?) can NOT fix this problem, they just hide the multiple NFS mount mess a little bit and cost way to much money. - For backups were large I/O are the norm; NFS is the most inefficient way of using your resources. - Get a real scalable filesystem, use a single mountpoint and drive your networks with optimal I/O speed. -frank- Frank Kraemer IBM Consulting IT Specialist / Client Technical Architect Am Weiher 24, 65451 Kelsterbach mailto:kraem...@de.ibm.com voice: +49-(0)171-3043699 / +4970342741078 IBM Germany -- Grant Street Senior Systems Engineer T: +61 2 9383 4800 (main) D: +61 2 8310 3582 (direct) E: grant.str...@al.com.au Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue Moore Park, NSW 2021 AUSTRALIA [LinkedIn] <https://www.linkedin.com/company/animal-logic> [Facebook] <https://www.facebook.com/Animal-Logic-129284263808191/> [Twitter] <https://twitter.com/AnimalLogic> [Instagram] <https://www.instagram.com/animallogicstudios/> [Animal Logic]<http://www.animallogic.com> www.animallogic.com<http://www.animallogic.com> CONFIDENTIALITY AND PRIVILEGE NOTICE This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
