Produktanfragen

Welcome to our product request board. We would love to hear your product suggestions!

Wir möchten wissen, was sich unsere Kunden und Partner von unseren Lösungen wünschen. Hier können Sie Produktvorschläge ansehen, einreichen und darüber abstimmen.

Idee einreichen
Nach Status filtern
Nach Produkt filtern
Filter by Product Category
Sortieren nach
6

NVMe over Fabrics (NVMe-oF) Support

Auf der Roadmap|SANsymphony

Problem to solve:
SCSI isn't the best protocol anymore for fast storage devices. Many storages nowadays have fast NVMe or SAS SSDs which offers much more IO Performance and short IO latencies. However, the performance is often limited over the FC transport if some server needs big IOs and some needs fast small IOs. The small IOs are often been blocked by the limitation of SCSI to only have one queue.
Small and stable latency is often much more important than pure bandwidth.

Proposed Solution:
First NVMe over Fabrics for frontend ports support, so the Datacore cache can be used with full protentional and fast small cached reads.
Second NVMe over Fabrics for mirror/backend ports, so that Datacore can retrieve the full storage performance in read and write.

5

Virtual Storport

In Bearbeitung|SANsymphony

Problem to solve:
The current Mini Port implementation for FC and loopback is sitting on an deprecated interface. Issues currently exist with:
- FC/loopback REFS
- Windows Clustering in HCI using loopback and FC
- MPIO integration to leverage ALUA on FC backend/mirror
This also creates performance limitations when SANsymphony is deployed in a "co-resident" HCI model with Microsoft Hyper-V.

Proposed solution:
Implement a new "virtual storport" that allows Microsoft based HCI configurations to be created and take advantage of FC adapter capabilities, when deployed in a "co-resident" HCI model with Microsoft Hyper-V. Also provide ALUA support for FC connected back-end storage.

3

VASA 3.0 Support

Auf der Roadmap|SANsymphony

Currently, our VASA provider adheres to VASA 2.0 Spec. This prevents our customers from taking advantage of HA, DR and SRM for VVols introduced in VASA 3.0 spec. Include support for async replication and CDP

2

vSphere 7.0 Certification

Released|SANsymphony|Done

Certify SANsymphony and integration components (core product and VASA provider) for the latest version of vSphere (7.0).

2

Regular Automatic Pool Maintenance

In Erwägung|SANsymphony

Problem to solve:
In the case of full recovery of a mirror vdisk SANsymphony can sometimes find bad blocks on the surviving Mirror side. After hitting a bad block the recovery fails and you must do a restore from backup and creates significant downtime.

Proposed Solution:
On a regular interval the pool driver should verify all SAU 's in the pool by reading them and comparing them against the mirror or checksum. If bad blocks are found a resync of the block should be done the affected SAU should be marked as defected.

2

Pool disk evacuation optimization

In Erwägung|SANsymphony

Problem to solve:
Pool disks are not evacuated one after another and mostly after hours or even days idling at a few GB allocation if at all. This allocates license volume needed for new storage to replace the old disks. This is a BIG problem when migrating big storage volumes.

Proposed Solution:
When multiple pool disks are tagged for evac disks should be evacuted one at a time until full removal and then the next one. Disks should not be idling with a few GB allocated for hours or even days without removal.

2

Extend Size of Pool Disks

In Erwägung|SANsymphony

Problem to solve:
Some Storage Arrays have the ability to resize the LUNs they present to SANsymphony. SANsymphony recognizes the new resize and counts it against the License Capacity, but it cannot detect the addition of the resized disk. The procedure to allow this to be detected is to mirror with a bigger disk then break it for SSV to see the new size. Often the additional space is just left unusable in the Pool.

Proposed Solution:
Allow SANsymphony to recognize the increased size when a LUN is extended in a Pool.

2

Disk remove from pool takes much too long

In Erwägung|SANsymphony

Problem to solve:
We have the challenge right now to reorganize our two disk pools with 40 TB each and built up new disk pools by using the existing disks. We have observed that removing a disc from the DiskPool is done at about 32GB/hour.
As the disk removal cannot speeded up today if though the Backend Storage is able to deliver over 1 Gb/s and is more or the less idling most of the time. We expect more than 100 days to finish the reorganization of the disk pools. Now I’m in the uncomfortable situation to explain this slow progress to my boss. I don’t want imagine what this slow removal means if I have to do this again with much larger Disk Pools.

Proposed Solution:
From my perspective an enhancement is needed to accelerate this ugly slow removal of a disk from a disk pool. A switch with options, such as – default (32 GB/h), fast (0.5TB/h), faster (1TB/h), automatic, urgent (as fast as possible) would be extreme helpful. possibly depending on the Tier class; Flash and NVMe can faster then NL Disk.
- Automatic in the sense that they the disk removal don't degrade the latencies or throughput for production. It would be great to have an box for
o entering the acceptable latency for the Backend and Frontend and
o limit the max. throughput used for migrations in the Backend

The possibility to give a little bit more speed after the end of production or on weekends would also be great. It could be something like shown in the following link of a Router which shows a timetable. I would have a better screenshot, but unfortunately I cannot attach screenshots here.

https://service.avm.de/help/de/FRITZ-Box-7590/017p1/hilfe_heimnetz_smarthome_wochentaegliche_schaltung

2

Advanced in-pool data protection

In Erwägung|SANsymphony|Work in progress

Problem to solve:
The current approach to provide software based data protection within SANsymphony pools is the concept of data mirroring. This protection method results in a 50% capacity loss from raw device capacity. There are more capacity efficient concepts available (e.g. RAID-5 or erasure coding) than mirroring to protect against device data loss and so called "silent bit-rot".

Proposed Solution:
Add additional, common data protection methods like X+1 or X+2 at the pool level, allowing more resilient distribution of data across disks in the pool.

1

VMware vCenter Plugin v2

Auf der Roadmap|SANsymphony

Need the ability to provision storage, interact with data services and have VM to storage visbility, natively in vCenter.