Картинка

БЛОГ про

все цікаве у світі телекомунікацій

Вибір обладнання для корпоративного хмарного сховища

2017-12-09
Автор: Телесфера

Корпоративне хмарне сховище

Дані - основа будь-якого бізнесу. Якщо місце їх зберігання недостатньо надійне або неспроможне забезпечити постійний доступ, то під загрозою буде практично вся діяльність підприємства.

Звичайно, можна і потрібно забезпечувати збереження і доступність інформації правильним вибором серверного ПЗ і грамотною конфігурацією. Але не менш важливе й залізо - обладнання, яке зберігає і обробляє дані. Якщо воно не відповідає потребам компанії, то ніякий софт не зробить його досить надійним і відмовостійким.

У цій статті ми розглянемо один з підходів до вибору заліза для створення корпоративного хмарного сховища.

Чому хмара?

Хмарна інфраструктура має ряд переваг:

  • Можливість швидкого масштабування. Збільшення ємності і обчислювальної потужності сховища досягається за допомогою швидкого підключення додаткових серверів і СГД. Особливо це актуально для компаній, у яких навантаження на хмару передбачається нерегулярне.
  • Зниження витрат. Хмара дозволяє створити єдиний центр, в якому будуть виконуватися всі обчислювальні процеси, в той час як для збільшення дискового простору буде достатньо простого придбання накопичувачів, без необхідності організації установки нових серверів.
  • Спрощення бізнес-процесів. Хмарне сховище, на відміну від локального, має на увазі можливість постійного доступу до нього. Це означає, що з файлами можна працювати в будь-який час доби з будь-якого місця. Співробітники зможуть отримувати необхідну для роботи інформацію простіше і швидше, стане можливим організувати віддалені робочі місця.
  • Підвищена відмовостійкість. Цілком очевидно, що, якщо дані зберігаються на декількох серверах, то їх збереження в разі технічних проблем буде вище, ніж якби вони знаходилися тільки на одній машині.

Чому своє?

Зараз на ринку є безліч публічних хмарних сервісів. Для багатьох малих і середніх компаній вони дійсно стають хорошим вибором, особливо якщо мова йде про послуги з оплатою тільки за використані ресурси або кваліфіковане проведення тестування сервісу. Однак своє хмарне сховище також дає ряд переваг. Воно стане до речі, якщо:

  • Діяльність компанії накладає обмеження на розташування серверів. Деякі держ. установи, а також організації, що займаються обробкою персональних даних, згідно із законом зобов'язані зберігати всю свою інформацію на території розміщення. Відповідно, орендувати закордонні сервери для них не представляється можливим, та й в цілому дуже не бажано довіряти делікатну інформацію підрядникам. Створення приватного сховища допоможе використовувати всі переваги хмари без порушення правових норм.
  • Необхідне повне управління політиками безпеки. Як влаштований захист даних в сервісах Microsoft або Amazon, точно дізнатися неможливо. Повністю зробити безпечною інформацію так, як ви вважаєте це за необхідне, можна тільки у власній хмарі.
  • Налаштування обладнання під себе. При оренді доводиться працювати з тим, що дає постачальник. Однак маючи в розпорядженні власні сервери, можна конфігурувати їх під рішення конкретних завдань саме для вашого бізнесу, а також використовувати те ПЗ, яким досконало володіє ваша IT-команда.

Вибір обладнання

При придбанні обладнання під хмарне сховище часто виникає питання: орендувати машини або купувати свої. Вище ми вже розбиралися, в яких випадках власний сервер незамінний. Однак організувати хмару можна і на сторонніх сервісах. Особливо це актуально для невеликих компаній, тому що не завжди є можливість виділити з бюджету необхідну суму на покупку серверів, не завжди є можливість створити власну серверну, та й не потрібно витрачатися на обслуговування машин.

Але якщо ви все ж вирішили брати власні сервери під хмарне сховище, то варто мати на увазі, що змінити обладнання буде проблематично і затратно. Не страшно, якщо потужності виявиться недостатньо: завжди можна додати ще одну машину в кластер. А ось якщо продуктивність виявиться надмірною, то з цим нічого вже зробити не вийде. Тому перед вибором варто зробити наступне.

Чітко визначити мету, для якої буде використовуватися сервер. У нашому випадку - це файлове сховище. Відповідно, найбільший інтерес представляють накопичувачі. На що слід звернути увагу при їх виборі:

Ємність. Залежить від того, скільки співробітників буде користуватися сховищем, які типи файлів вони будуть закачувати на сервер, скільки інформації вже зараз чекає перенесення в хмару і на скільки збільшується обсяг робочих даних щорічно.

В середньому для роботи з текстовими файлами, презентаціями, PDF і невеликою кількістю зображень потрібно в середньому 10-15 Гб на співробітника. Для роботи з великими обсягами високоякісних картинок і фотографій потрібно збільшити мінімум до 50-100 Гб, а то і більше. Потреби персоналу, що займається обробкою відео і аудіо, можуть досягати декількох терабайт на людину. У ряді випадків, наприклад, при використанні великих корпоративних програмних пакетів з підтримкою версійності проектів, мова може йти і про 10 терабайт на одного користувача хмари. Не забудьте врахувати ємність під резервні копії файлів і непередбачені потреби компанії.

Що стосується RAID-контролерів, то для корпоративної хмари краще не використовувати набортні рішення. Їх продуктивності може виявитися недостатньо для обслуговування великої кількості запитів з задовільною швидкістю. Так що краще вибрати дискретні моделі з нижнього і середнього цінових діапазонів.

Також необхідно визначитися з обчислювальною потужністю. Якщо ви створюєте хмарне сховище на базі декількох серверів, то рекомендується підбирати ідентичні або дуже близькі конфігурації. Це дещо спростить управління розподілом навантаження. І взагалі краще не робити ставку на одну потужну машину, комплектуючи її дорогим процесором і оперативною пам'яттю, а купити дешевше 2-3 машини. Чому?

Якщо ваше сховище буде тільки приймати і віддавати статичні файли, без можливості їх запуску, то потужність процесора не дуже важлива. Тому краще не гнатися за кількістю ядер і вибрати модель з хорошим «тактом».

Приклади моделей серверів

Якщо ви вважаєте за краще не збирати сервер самостійно, а відразу купувати готове до роботи обладнання, то зверніть увагу на декілька відповідних моделей для створення файлового сховища.

Dell PowerEdge T110. Сервер оснащений процесором Intel Core i3 2120 з усього двома ядрами, але зате кожне з них має непогану тактову частоту в 3,3 ГГц, що для нашої хмари важливіше. Початкова конфігурація оперативної пам'яті не дуже велика - 4 Гб, однак може бути розширена до 32 Гб. Сервер поставляється в двох комплектаціях - без встановленого жорсткого диска або з HDD-накопичувачем ємністю в 1 Тб і інтерфейсом SATA.

Lenovo ThinkServer RS140. Має потужний процесор Intel Xeon E3 з чотирма ядрами по 3,3 Ггц кожне. Оперативна пам'ять «з коробки» - 4 Гб, плюс ще чотири слота для її розширення. Також в комплект входять два жорсткі диски по 1 Тб з SATA-інтерфейсом.

HP ProLiant ML10 Gen9. Багато в чому схожий з описаною вище моделлю - все той же Intel Xeon E3 та два терабайтових HDD. Основна відмінність в оперативній пам'яті - сервер HP має дві пластини по 4 Гб кожна.

Чи достатньо місця для зберігання файлів?

Обсяг сховища - наріжний камінь файлового сервера. Провівши оцінку обсягу збережених даних і динаміки зростання, можна через півроку прийти до неприємного висновку, що з прогнозом ви помилилися, і дані ростуть швидше, ніж планувалося.

У разі віртуалізації сховища ви практично завжди (при розумному підході до планування СГД) зможете розширити дискову підсистему віртуальної машини або збільшити LUN. У разі фізичного файлового сервера і локальних дисків, ваші можливості будуть значно скромніші. Навіть не дивлячись на наявність вільних слотів в сервері для додаткових дисків, можна зіткнутися з проблемою підбору накопичувачів, що підходять для вашого RAID-масиву.

Але перш ніж вирішувати проблему екстенсивним шляхом, слід згадати і про технічні засоби, які допомагають боротися з нестачею місця.

Дискові квоти NTFS

Один з найстаріших і надійних механізмів обмеження користувачів - квоти файлової системи.

Включивши квоти для тому, ви можете обмежувати обсяг файлів, що зберігаються кожним користувачем. У квоту користувача потрапляють файли, для яких на рівні NTFS він є власником. Головним недоліком механізму є те, що, по-перше, не так просто визначити, які файли належать конкретному користувачеві, а по-друге, файли, створені адміністраторами, не будуть включені в квоту. Механізм квот рідко використовується на практиці, його практично повністю замістив File Server Resource Manager, що вперше з'явився в Windows Server 2003 R2.

File Server Resource Manager

Цей компонент Windows Server дозволить квотувати дисковий простір на рівні конкретної папки. Якщо ви виділяєте для співробітників персональні домашні каталоги на файлових серверах, а також виділені папки для загальних документів відділів, то FSRM - найкращий вибір.

Звичайно, квотування саме по собі не збільшить обсяг файлового сховища. Але користувачі, як правило, лояльно відносяться до справедливого (рівного) поділу ресурсів, а в разі нестачі готові подолати невеликі бюрократичні процедури для розширення дискового простору.

Квоти допоможуть і від перевантаження сервера в разі випадкового розміщення користувачем великого обсягу інформації. У всякому випадку, це не позначиться на інших співробітниках або відділах.

Крім того, FSRM включає в себе механізм «скринінгу» (фільтрації) файлів, які можна зберігати на сервері. Якщо ви впевнені в тому, що mp3- і avi- файлам не місце на файловому сервері, то можна заборонити їх збереження засобами FSRM.

Компресія NTFS

Звичайні файли добре піддаються стисненню засобами NTFS, а з урахуванням продуктивності сучасних процесорів, у сервера достатньо ресурсів на цю операцію. Якщо місця не вистачає - можна сміливо включати її для тому або окремих папок. Наприклад, в Windows Server 2012 з'явився більш досконалий механізм, при використанні якого NTFS-стиснення на файлових серверах для більшості сценаріїв залишається в минулому.

Дедуплікація

Windows Server 2012 включає в себе можливість дедуплікаціі даних, розташованих в томі NTFS. Це досить просунутий і гнучкий механізм, що поєднує в собі як Дедуплікація зі змінною довгою блоку, так і ефективну компресію блоків, що зберігаються.. При цьому для різних типів даних механізм може використовувати різні алгоритми стиснення, а якщо стискання не ефективне - не використовувати його. Такі тонкощі недоступні традиційному стисканню засобами NTFS.

Крім того, дедуплікація НЕ оптимізує файли, з якими користувачі працювали останні 30 днів (цей інтервал можна налаштувати) для того, щоб не знижувати швидкість роботи з динамічно змінюваними даними.

Оцінити потенційну надбавку вільного місця можна утилітою ddpeval. На типовому файловому сервері економія становить 30-50%.

Продуктивність файлового сервера

Як ми зазначали раніше - файловий сервер не найвимогливіший до ресурсів сервіс, але все ж слід розумно підійти до конфігурації дискової і мережевий підсистем.

Дискова підсистема

Лінійна швидкість читання або запису не грають для файлового сервера вирішального значення. Будь-який сучасний жорсткий диск має високі характеристики лінійної швидкості читання/запису, але вони важливі лише в тих випадках, коли користувач копіює до себе на локальний диск великий файл, або, навпаки, розміщує його на сервері.

Якщо подивитися на статистику Perfmon, середня швидкість читання/запису для 150-200 користувачів досить низька і становить всього лише кілька мегабайт в секунду. Більш цікаві пікові значення. Але слід мати на увазі, що і ці піки обмежені швидкістю мережевого інтерфейсу, а для звичайного сервера це 1 Гбіт/с (тобто 100 Мб обміну з дисковою підсистемою).

У звичайній роботі доступ до файлів йде нелінійно, з диска зчитуються і записуються довільні блоки, тому більш критичним є продуктивність диска в операціях випадкового доступу, тобто максимальний IOPS.

Для 150-200 співробітників показники досить скромні - 10-20 операцій введення виведення в секунду з дисковою чергою в межах 1-2.

Цим вимогам задовольнить будь-який масив зі стандартних SATA дисків.

Для 500-1000 активних користувачів кількість операції підскакує до 250-300, а дискова черга досягає 5-10. Коли черга досягає цієї величини, користувачі можу зауважити, що файловий сервер «пригальмовує».

На практиці для досягнення продуктивності в 300 IOPS вам вже буде потрібен масив як мінімум з 3-4 дисків типових SATA-дисків.

При цьому слід врахувати не тільки «сиру продуктивність», а й затримку, що вноситься роботою RAID-контролера - так звану RAID penalty.

Для визначення необхідної кількості дисків використовуємо формулу:

Total number of Disks required = ((Total Read IOPS + (Total Write IOPS*RAID Penalty))/Disk Speed IOPS)

RAID-5 з penalty на запис в 4 операції, профілем читання 50%, запис 50%, швидкістю диска в 75 IOPS, цільова продуктивність в 300 IOPS:

(300*0,5 + (300*0,5*4))/75 = 10 дисків.

Якщо у вас багато активних користувачів, то вам буде потрібен ємний сервер або більш продуктивні диски, такі як SAS зі швидкістю обертання 10 000 RPM.

Швидкість мережевого інтерфейсу

Низька швидкість мережевого інтерфейсу - одна з причин затримок при роботі з файловим сервером. У 2016 році сервер з 100 Мбіт/с мережевою картою - нонсенс.

Типовий сервер обладнаний мережевою картою зі швидкістю 1 Гбіт/с, але і це обмежує дисковий обмін швидкістю близько 100 Мб/с. Якщо в сервері кілька мережевих карт, то ви можете об'єднати їх (агрегувати) в один логічний інтерфейс для збільшення як продуктивності, так і доступності хмари. Хороша новина в тому, що для файлового сервера ( «багато клієнтів звертаються до одного сервера») агрегація працює добре.

Власники серверів HP можуть використовувати фірмову утиліту HP Network Configuration Utility

Якщо ви використовуєте Windows Server 2012, то більш простим і надійним способом буде використання штатного кошти NIC Teaming.

Джерело: https://habrahabr.ru/company/pc-administrator/blog/309390/


 Про компанію Телесфера Інтеграція.

Телесфера Інтеграція заснована в 2012 році та являється інтегратором новітніх технологічних рішень для бізнесу.  Ми розробляємо рішення, що роблять Ваш бізнес успішним.

Основні напрямки роботи компанії:

  • Побудова локальних обчислювальних мереж;
  • Налаштування мережевого обладнання передових виробників (Cisco Systems, Aruba Networks та інших);
  • Продаж телекомунікаційного обладнання;
  • Аудит локальних обчислювальних мереж;

e-mail: office@telesphera.net
Телефон: (093) 198-11-82

КОММЕНТАРІ ДО СТАТТІ

Налаштування QoS на пограничному маршрутизаторі Cisco

Налаштування QoS на пограничному маршрутизаторі Cisco
cisco,router,Налаштування,QoS,Налаштування Cisco

Пограничний маршрутизатор в мережі офісу це точка, де вирішується доля всього мережевого трафіку, що прямує в Інтернет. Саме пограничний маршрутизатор вирішує, який трафік надіслати без затримок, а який притримати і пропустити потім.

Чотири причини замінити брандмауер вашої філії удосконаленою захищеною SD-WAN

Чотири причини замінити брандмауер вашої філії удосконаленою захищеною SD-WAN
Aruba Networks,Блог Телесфера,Налаштування Aruba Instant,Налаштування Aruba

Був час, коли рішення SD-WAN були орієнтовані лише на віртуалізацію WAN без особливих міркувань безпеки. Щоб заповнити цю прогалину в безпеці, з'явилися передові безпечні рішення SD-WAN, які включають найвищі можливості захисту від загроз. Фактично розширені функції безпеки, які тепер підтримуються на передових платформах SD-WAN, дозволяють клієнтам повністю відмовитися від виділених міжмережевих екранів філій і ще більше спростити інфраструктуру філій WAN.

Безкомпромісна SASE: Aruba Secure SD-WAN і Netskope SSE

Безкомпромісна SASE: Aruba Secure SD-WAN і Netskope SSE
Aruba Networks,Блог Телесфера,Налаштування Aruba

Програми SaaS, робочі навантаження IaaS, розповсюдження пристроїв IoT і гібридна робоча сила продовжують спонукати підприємства переглядати свої глобальні мережі та архітектури безпеки. Традиційні технології WAN, які базувалися на жорсткій архітектурі WAN, орієнтованій на маршрутизатор, повільно реагували на потреби бізнесу, пропонували непостійну якість роботи та були складними в управлінні. SD-WAN забезпечує кращу та стабільнішу продуктивність хмарних додатків, консолідує функціональні можливості глобальної мережі та підтримує нульову довіру та структуру SASE. Минулого року IDC дослідила Північну Америку та виявила, що 72% підприємств планують перейти на SD-WAN у 2021–2023 роках (1).