VMAX 950F is the newest member of VMAX All Flash family. EMC claims performance that is 68% faster and offering 30% better response times (6.7 million IOPS) than the previous generation.The VMAX 950F array uses Intel CPUs with software enhancements. The VMAX performs on a single platform with a 25% smaller footprint for the same performance as the previous generation.
XtremIO is a platform that allows deduplication and integrated copy data management (iCDM) for large-scale snapshots, such as VDI and development/test use cases. EMC claims that X2 offers up to 80% lower response times and 25% higher data reduction. EMC has also made the X2 more efficient with all-flash performance storage capacity, as well as making the price as low as one-third of cost of the X1.
This generation of Isilon systems will include all-flash, hybrid and archive configurations. The 'Infinity' architecture delivers up to 6x the IO/s, 11x the throughput, and 2x the capacity of the current generation Isilon platform. A new modular design simplifies performance and/or capacity upgrades. This generation of Isilon systems can integrate with existing Isilon clusters, or can be deployed as a new cluster. The Isilon will update All-Flash, Hybrid Platforms, and Archive Platforms.
For All-Flash platforms: the Dell EMC Isilon F800 provides “extreme performance and efficiency for the most demanding unstructured data applications and workloads” and will be available soon.
There are three new Dell EMC Isilon hybrid platforms: the Isilon H600, Isilon H500 and the Isilon H400. These three platforms will be delivering up to 120k IOPS, 3 GB/s-12GB/s bandwidth and up to 480 TB capacity per chassis.There are two archive systems that are being updated: the Isilon A200 and the Isilon A2000. These two systems help the need for efficient and secure data. They will both provide active and deep archive storage. The new platforms are designed to integrate into existing Isilon clusters.
Having done your homework, you may very well know a hybrid solution can offer the best price/performance option. The question then becomes what percentage of your data storage capacity should be flash and what percentage should be traditional disk? In terms of an IOP density function, the following ratios can be used when empirical data is not available: 69% of IOPS tend to occur on the first 20% of storage, 20% occur on the next 20%, and 11% of IOPS relate to the last 60% of the storage capacity. As a result, placing 40% of your data on flash suggests you will get 89% of your IOPS.
The science of genome sequencing is evolving much faster than the refresh cycle of data center equipment. As a result, it is incumbent on IT to purchase equipment with sufficient flexibility to anticipate new sequencing demands. Just what exactly are the factors that drive those demands in terms of compute and data storage resources?
Genome sequencing usually means creating an enormous database, and then mapping it against the variant in question. This requires a sort step of the read mapping. While this process can arguably be done more efficiently in some cases by using third party software, it’s still a very-compute intensive undertaking. For example, a recent study of 440 patients required 300,000 core hours of computer time.
Currently, each genome read mapping uses approximately 500 core hours of processing. Given the cost of a core hour is between $.05 and $0.12, add in the variant calling cost of about 200 core hours per genome, and one can quickly get an idea of the compute resources required. As far as storage performance, a reasonable heuristic is 10 sustained IOPS per study participant, and at least 1 GB/s of sustained reads. However, the latency requirements are much more modest than the required data transfer rate would suggest. Therefore, genome sequencing is arguably an optimal workload for a hybrid data storage solution.
There are two distinct methods of genome sequencing: whole genome sequencing, and exome sequencing. Whole, as the name implies, includes sequencing the non-differentiated aspects of the human genome, while exome only sequences the exonic aspects, which typically amount to 1-2% of the whole genome. As a result, the amount of data storage and disk IOPS required will depend on sequencing approach (whole or exome), plus the number of base reads, and the read length.
In the case of exome sequencing, the file size can be derived from: a coverage factor of 40x, 110,000,000 reads and a read length of 75. This will give you a 5.7GB BAM file. Add in meta data for future analysis and visualization, and the expanded file will be almost 7GB.
In the case of whole genome sequencing, if we use fairly standard measures such as coverage of 37.7 x, a read length of 115, with 975,000,000 reads, the BAM file would be 82GB. Adding meta you can expect the BAM file size to be about 105 GB.
Processing resource requirements in combination with disk IO are slated to increase as HighSeq x 10 analysis becomes increasingly common. For rough estimate purposes, each read mapping requires about 500 core hours while each variant calling needs 200 core hours. These numbers will trend upwards fairly dramatically if HighSeq x 10 is fully exploited.
Finally, one of the constraining factors in designing a storage solution for genome sequencing is not only high IOPS requirements, but also the ability to move data blocks of varying sizes at 1GB/s transfer rates or more.
One of the more interesting questions concerning the use of flash storage is its value for Oracle redo logs. It turns out, that the answer is not as straight forward as we might like. Instead, it depends upon the characteristics of the workload under consideration, and the design of your selected flash system. For example, a flash product may have an inherent feature whereby there is a performance penalty for writes which are not aligned on 4K boundaries. If this is the case, then the penalties for misaligned random writes are much greater than for misaligned sequential writes of the same size. Second, as write sizes increase, the misalignment penalties (in percentage terms) decrease dramatically, especially in the sequential case. Since all database writes in Oracle are aligned on 4K boundaries (as long as the default block size is at least 4K), using flash for database table spaces should never result in slower performance due to misaligned writes. On the other hand, redo writes are only guaranteed to fall on 512 byte boundaries. To complicate things a little further, redo writes also have a quasi-random access pattern when async I/O is employed. These two properties together will contribute to performance degradations for some workloads.
Reading a file out of storage causes it to be reconstituted and therefore any secondary copy will be larger than the primary. If a file is snapshotted before deduplication, the post-deduplication snapshot will preserve the entire file. This means that while the storage space due to deduplication of primary files may shrink, the storage capacity required for snapshots may expand dramatically.
Scaling can be a bit of a challenge for systems that use deduplication because ideally the scope of deduplication needs to be shared across storage devices. If you have multiple backup devices in your infrastructure with discrete deduplication, then space efficiency maybe adversely affected.
In the case of an analytic workload, setting up file systems to support the typical amount of data, as well as having sufficient disk space for temporary files, can be very challenging. In addition, ensuring there is sufficient sustained IO bandwidth to complete jobs within the time allotted can be a challenge. In general, file systems striped across many smaller disks work more effectively than the use of a few larger disks. Therefore, the focus shifts away from IOPS to sustaining a high level of througHPEut. Generally speaking, analytics tends to be highly sequential. However, when each user has their own session, if more than one session is trying to access the same data file, it may appear to the data storage system that this workload has a random component. If you are using SAS, then your performance may be limited by the file system cache. The maximum file system cache througHPEut is about 2 GB/s on UNIX and Linux and 1.4 GB/s on a 64 bit Windows machine.