Product specifications

Managing Storage Groups
64
However, in an unprotected state, due to the distributed architecture of the ISIS file system (optimized for real-time
performance), it is possible under certain circumstances that the system would not be able to correctly update the
parity information when writing new data. As a result under these circumstances, the file system could return a
failure status when writing. While the failure rate percentage on the total number of write operations is low, heavy
workloads on the system would result in enough write failures to disrupt operations.
This issue only applies when the Workspace is in an unprotected state and the remove redistribution process on the
failed ISBs has not been initiated. Therefore, Avid highly recommends that you initiate the remove redistribution
process immediately upon confirmation of any ISB failure. This ensures immediate protection (RAID-6 or
mirroring) of new data being written, and full protection of all stored data at the earliest possible time.
Mirrored Workspace, Single ISB Failure
An “unprotected state” occurs when you have a single ISB failure in a mirrored Workspace. In an unprotected state
with no additional failures, read operations continue to function normally.
However, in an unprotected state a subsequent or infrastructure failure will cause operational issues which could
result in failures when writing new data or prevent you from accessing data in the Workspace. An additional ISB
failure can compromise data accessibility. Networking issues, on the other hand, will not cause accessibility issues
on previously written data but might prevent the successful completion of an active write operation.
This issue only applies when the Workspace is in an unprotected state and the remove redistribution process on the
failed ISBs has not been initiated. Therefore, Therefore, Avid highly recommends that you initiate the remove
redistribution process immediately upon confirmation of any ISB failure. This ensures immediate protection
(RAID-6 or mirroring) of new data being written, and full protection of all stored data at the earliest possible time.
Matching Chunk Sizes to the File System
If you add an ISB (displays as an available Storage Manager) to your file system, make sure you match the chunk
size of the new Storage Manager to the chunk size of the existing Storage Group. New Storage Managers are added
with a default chunk size of 512 KB on mirrored Storage Groups (256 KB with i1000 ISBs). You cannot mix the
chunk sizes within a Storage Group. To change the chunk size of an ISB, you must remove the Storage Manager
from the file system and add the Storage Manager again (rebind it), selecting the same protection and chunk size as
the existing Storage Group.
Zone 1 Switches
The ISIS v2.x generation IXS and ISS switches install in the same engines as earlier releases; the chassis has not
changed. However, all the switches in the engines must be of the same generation. The two new switches are labeled
IXS2000 and ISS2000. The new switches cannot be mixed in ISIS Engines with earlier versions of the switches
(labeled IXS1000 and ISS1000). If your IXS and ISS switches are not labeled, consider them the earlier versions.
The ISS2000 switches are required for 10 Gb clients and 512 KB chunk size, see
“Storage Groups and Chunk Sizes”
on page 63
.
The Avid ISIS documentation refers to IXS2000 and ISS2000 switches as v2.x hardware and IXS1000 and ISS1000
switches as v1.x hardware.
Storage Groups on ISIS | 5500 and ISIS | 2500
For both ISIS | 5500 and ISIS | 2500, each Engine is a Storage Manager. You can assign all of your Engines to one
large Storage Group, or each Engine can be a Storage Group. An Engine can be assigned to only one Storage Group.