| № | Вопрос | Ответ |
|---|---|---|
| 1. | Какие алгоритмы предугадывания операций чтения используются в BAUMSTORAGE? Какие метрики позволяют определить последующий предполагаемый блок данных, который может быть зачитан приложением? | В BAUMSTORAGE используется алгоритм кеширования ARC. При чтении сначала данные ищутся в кэше, и затем только на диске. При переполнении кэша данные вытесняются в кэш второго уровня, расположенный на быстрых SSD дисках. |
| 2. | Макс размер кэша на контроллер. Возможность партиционирования кэша. Возможность зеркалирования кэша на запись между контроллерами. Процессоры контроллеров. Поддержка flash cache, разные или одинаковые ssd для кэша и для хранения. |
RAM кэш (на контроллер) – 1024 Гбайт SSD кэш чтение (на контроллер) – 30 Тбайт NVDIMM Кэш на запись 16 Гбайт SSD кэш на запись – 3,2 Тбайт (не используется одновременно с NVDIMM кэшем);
|
| 3. | Какой размер чанка у кэша на запись? | Система имеет динамический размер чанка на запись, который зависит от нескольких параметров: входной поток запросов от клиента, и выходной поток запросов к дискам. Контроллер динамически изменяет размер сбрасываемых в кэш на запись данных в зависимости от того, какая даётся нагрузка. Таким образом достигается равномерность выполнения запросов и предотвращается разрастание буферов и кэшей. Кроме того, система может выбирать, куда сбрасывать запросы на запись – в основной массив (на HDD), в его диски под кэш на запись (на SSD), или же в кэш на запись основного массива (на HDD, только в спец. журнал). Это позволяет в некоторых случаях уменьшить нагрузку на SSD. В версии 4.0 предусмотрен изменяемый параметр ресурса, который отвечает за политику обработки синхронных операций ввода-вывода (при монтировании с sync (тома) или открытии с флагом O_SYNC (ФС)). По умолчанию (как и в 3.5) используется политика наименьших задержек (в этом случае может использоваться выделенный диск/диски под кэш на запись). В 4.0 будет возможность установить политику наибольшей пропускной способности. В этом случае синхронные операции будут оптимизированы таким образом, чтобы увеличить пропускную способность всего всех ресурсов массива, а диски под кэш на запись использоваться не будут. |
| 4. | Будет ли нарушение целостности RAM кэша при отказе одного контроллера или при отключении всех вводов питания ? | При отключении всех вводов будет потеряно то что успело прийти в RAM кэш за последние 5с |
| 5. | Почему один из дисков можно добавить в кэш записи, одновременно в несколько пулов, притом второй диск в будет отличаться | рейд1 для вр-кешей создается не на уровне дисков, а на уровне партиций. Поэтому эта ситуация вполне штатная для нашего ПО. Отказоустойчивость кеша сохраняется, смешивания кешей пулов – нету.
Допустим, есть три диска под вр-кеши, по четыре партиции в каждом. Добавляем диски 1,2 в pool1, а в pool2 добавляем диски 2,3. Тогда структура пула будет выглядеть примерно так (обратите внимание на общий диск 2): pool1 <…> wr-cache-mirror: disk1_p1 disk2_p1 pool2 <…> wr-cache-mirror: disk2_p2 disk3_p1 |
Отслеживать