Отже, у нас є система зберігання даних (СЗД), що складається з двох контролерів 3220, п'яти полиць по 24 диска кожна, диски 600ГБ SAS 10k RPM, FlashCache 1ТБ (по 512 МБ на контролер), сира ємність системи становить 5 x 24 x 0, 6 = 72ТБ.
На СГД буде хоститься віртуалізація Vmware, для простоти на NFS, щоб не возитися з резервами на LUN і VMFS.
У зв'язку з особливостями володіння дисками в netapp, враховуючи що будемо хостити віртуалізацію, для розпаралелювання навантаження на контролери ділимо загальну масу дисків навпіл і кожну половину віддаємо у володіння своєму контролеру. Разом на кожен контролер виходить по 60 дисків.
Разом виходить. 18 950ГБ, ну нехай 19ТБ на контролер, 19 x 2 = 38ТБ на масив. Це 53% від сирої ємності. А якщо врахувати, що забитий на 100% масив працювати не буде, то вважаємо що його максимальна заповненість, при якій він ще буде швидкий, становить близько 80%, тобто реально в вашому розпорядженні 30,4ТБ, 42% від сирої ємності.
Далі, якщо у вас не NFS, а LUN-и і VMFS, то потрібно відняти оверхед ще й на цю справу (на LUN-и так і бути, нічого, на VMFS - 10%).
У ньому виходить 45,5ТБ. см. Рис. 1
Наступного разу будемо оцінювати кількість IOPs-ів для цієї ж конфігурації СГД. А в наступний-наступного разу такий же Марлезонського балету зробимо для EMC VNX.
Вітання. «Краще пізно, ніж ніколи» 🙂
Кілька поправок.
1. «Для розміщення ОС контролерів резервуємо по 3 диска на контролер»
Варто відзначити, що відвести виділені диски під root volume для Data ONTAP це _рекомендація_, причому застосовна до досить великим і «крутим» системам, а зовсім не _требованіе_.
Тому що люди, які хочуть купити 2240 на 24 диска подивляться на це, злякаються і введуть в оману, що ніякого іншого варіанту крім віддати 3 диска «за так» їм не предлагают.Хотя це не так навіть за рекомендаціями NetApp (див. Storage Subsystem FAQ , мабуть доступний вам).
Для _рассматріваемой_, досить великий системи - так, я б теж робив так. Але варто було б уточнити в явному вигляді цей момент для читачів не в повному обсязі володіють предметом.
2. «але аж надто великий оверхед на парність вийде в такому варіанті»
Що ви маєте на увазі під «оверхедів на парність»? З мого досвіду немає помітної оці різниці в погіршенні швидкодії групи на 14D + 2P і максимально підтримуваної 26D + 2P, що пов'язано з механізмом роботи RAID-DP, відрізняється від RAID-6. Є поліпшення за рахунок більш високого паралелізму введення-виведення на довгій групі. Єдиний відомий недолік довгих груп у NetApp FAS - це деяке погіршення з часом відновлення після виходу з ладу диска в ході «перерахунку» RAID. Саме час відновлення і є визначальним для вирішення використовувати групу певної довжини. І вже абсолютно точно я б вибрав трохи довшу групу, щоб уникнути неповної групи в aggregate, це і правильно архітектурно, і рекомендується NetApp.
До слова, групи довжиною 20-22 диска часто-густо працюють в реальних системах в продакшн, за рахунок принципів роботи RAID-DP, що відрізняються від принципів RAID-6, від «оверхедів на парність» вони не страждають.
3. «Ємність = кол-во_дісков x реальная_емкость_діска. Реальну ємність диска можна подивитися тут. У нас виходить 47 x 560ГБ = 26 320ГБ »
Варто було б хоча б одним реченням зупинитися на тому, що це за «_реальная_емкость_дісков_», звідки береться, і як вона отримана. І чому вона вказана не в GB, а в GiB (вірніше навіть в MiB), у себе ви бінарний префікс опустили, це недобре. Знову виходить плутанина.
Також хочу відзначити, що ви, в свою чергу, також потрапляєте на «помилку округлення». Ємність в 560.000 MiB НЕ дорівнює 560GB, як вказана у вас, вона дорівнює 560.000 MiB / 1024 = 548,875 GiB
Давайте вже, якщо почали рахувати, складати метри з метрами і фути з футами.
4. «Резервування під снепшот 20% (значення за замовчуванням),"
Для даної системи це вірно, так як в умовах - NFS. Але нижче, коли ви пишете про варіант з LUN і VMFS:
«Далі, якщо у вас не NFS, а LUN-и і VMFS, то потрібно відняти оверхед ще й на цю справу (на LUN-и так і бути, нічого, на VMFS - 10%).»
то варто було б уточнити, що цей «10%» не вираховується з результату отриманого при NFS, а навпаки, «додається», тому що для LUN рекомендований розмір snapshot reservation дорівнює 0% замість 20% для NFS (див. Best Practices), і з цього 0% вже віднімається 10% «на VMFS». У вас це для людини не володіють матеріалом не цілком ясно написано, і він може вводитися в оману, що в разі LUN / VMFS у нього заберуть молодого 20% + 10% = 30%, хоча це не так.
Можливо тому, що Synergy вважає трохи коректніше, в ньому і виходить більше.
Проте, недивлячи на ці невеликі недоліки, підрахунок корисний і в цілому коректний, спасибі, чекаємо такої ж для інших вендорів, обіцяний для VNX.
Про Дедуплікація, flexclone та інше - це занадто залежить від конкретних умов конкретного проекту. Що будуть зберігати, наскільки готові пожертвувати продуктивністю заради обсягу, наскільки бояться тонкощів і снепшотностей (так, психологія та упередження таки теж грають!). Загалом, я завжди намагаюся вважати варіант виходячи з найгірших припущень і потім, у міру просування вперед, його покращувати.
> «Або взагалі помістити rootvol на агрегат з іншими даними (хоч це і не рекомендується»
Storage subsystem FAQ, сторінка 5
SHOULD I USE A DEDICATED ROOT AGGREGATE?
A dedicated root aggregate is an aggregate that contains only a root volume; that is, it does not contain any user data volumes. Using dedicated root aggregates for Data ONTAP operating in 7-Mode is not required, but it is recommended.
Строго кажучи, практична необхідність виводити root volume на виділений aggregate має істотну важливість переважно для великих систем. Наприклад, у свій час, до 8.0.1 здається, не можна було розміщувати root volume на 64-bit aggregate, також виділений aggregate c кщще важливий для ultra-high available систем з вкрай жорстким SLA, типу Metrocluster.
Але в житті принципову необхідність виділяти окремий aggregate під root volume, в 95% випадків, немає потреби. Он, навіть в Synergy це окрема опциональная галочка.
Тим більше, що навіть у наведеній вами сторінці там же другим рядком написано:
«However, for small storage systems where cost concerns outweigh resiliency, a FlexVol based root volume on a regular aggregate might be more appropriate.»
І, так, варто було б відзначити, що required воно стає для систем в Cluster-mode, ось тут - так. Так як cluster-mode у нас вже зовсім поруч, пора вже це спеціально обумовлювати і враховувати.
> Для якогось N-ска, загубленого в лісах Сибіру, де вихід з ладу диска не помічають по 2 тижні, а потім ще місяць-два везуть заміну, а бекап робиться снепшот - це суттєвий ризик.
В цілому, не думаю, що збільшення розміру групи з 7 до 9 дисків несе якісь помітні візуально ризики в плані збільшення тривалості відновлення і зменшення надійності, а ось ємність 4 дополнітелной дисків в систему воно нам повертає. Такий, більш гнучкий підхід мені здається в даному випадку більш практичним і застосовним. Але, згоден, це деталі.
> Загалом, я завжди намагаюся вважати варіант виходячи з найгірших припущень і потім, у міру просування вперед, його покращувати.
В цілому це вірно, але тут варто враховувати призначений для користувача user experience, який, для «звичайних» систем зберігання говорить, що після того, як ми створили і сконфигурировали чисту і порожню систему зберігання, її доступна ємність, у міру записи на неї даних, може для користувача тільки зменшуватися (що логічно і з точки зору банальної життєвої логіки).
Однак в разі NetApp це не так, і ось на це варто було б звернути увагу читача, так як це йде врозріз з його «уявленнями за замовчуванням», але цей аспект usable space на NetApp досить важливий в конфігурації і розумінні того, «як все працює ».