none
Отказоустойчивое хранилище. Вопросы по конфигурации RRS feed

  • Вопрос

  • Добрый день.

    У начальства возникла идея поменять текущую конфигурацию файлового сервера, а именно один виртуальный сервер с отдельным диском под хранилище на 17ТБ, на что-то более отказоустойчивое. В требованиях выделили 2 сервера через которые будет проходить соединение с хранилищем и само хранилище, которое будет оставаться доступным при выходе из строя одного из новых серверов. При этом решение не должно быть сильно затратным и не повлияет на резервное копирование.

    Покурив интернеты у меня получилось найти несколько вариантов, но ни один из них не соответствует всем требованиям:

    1) Использование CSV (Cluster Shared Volume) диска, подключенного к отказоустойчивому кластеру из двух серверов. Все круто, но смущает один момент, вот тут - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831349(v=ws.11) написано что CSV не поддерживает использование FSRM и дедупликацию. Хотя в другой статье написано что CSV с системой NTFS поддерживает дедупликацию https://support.microsoft.com/en-us/help/2906888/known-issues-after-you-enable-data-deduplication-on-csv. 

    2) Использование двух серверов со storage spaces или DFSR. В этом случае получаются слишком большие затраты на зеркалирование хранилища. При использовании storage spaces нужно на каждый сервер добавлять диски, которые будут собираться в программный RAID, в случае с DFSR на каждом сервере будет полная копия всей шары и это тоже выходит слишком дорого.

    3) Включать Fault Tolerance для этого сервера на гипервизоре. В этом случае не будет возможности делать резервные копии сервера.

    4) Ради надежности можно переключить хранилище на core версию, а при падении сервера восстанавливать его через instant recovery в veeam. В этом случае вырастет время простоя, но зато нет дополнительных затрат.

    Есть ли еще какие-нибудь варианты реализации такой схемы? Поддерживается в итоге дедупликация на CSV или нет? И будет ли работать FSRM+CSV?

    6 октября 2018 г. 20:39

Ответы

  • Сервер используется как хранилище пользвательских рабочих файлов. Pdf, текстовые файлы, таблицы и т.д. Win server позволяет удобно делать smb шару, которую можно настроить через FSRM.

    многие из упомянутых вами решений не подходят под пользовательские данные. Например на csv нормально работают огромные файлы дисков виртуальных машин или sql базы, ко как только сотня пользователей начнет читать/писать мелкие jpg/pdf/txt так сразу появятся дикие фризы. 

    Поэтому я бы сказал что оптимальным путем было бы дробление ресурса и презентация его через dfs на разных серверах. В такой схеме вы получите и все плюшки fsrm, и 0 издержки на дополнительный сторажд, и в случае выхода одного сервера из строя, часть ресурсов останется доступной, пока вы будете восстанавливать вторую часть.

    + если данные на сторажде не пострадали вы можете просто переподключить лун от упавшего сервера на новый и не заниматься восстановлением бекапа.


    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа Валера2 7 октября 2018 г. 18:32
    7 октября 2018 г. 16:15
    Модератор

Все ответы

  • для каких задач вы используете свой сторадж и зачем в этой схеме win server?

    The opinion expressed by me is not an official position of Microsoft

    7 октября 2018 г. 13:27
    Модератор
  • Сервер используется как хранилище пользвательских рабочих файлов. Pdf, текстовые файлы, таблицы и т.д. Win server позволяет удобно делать smb шару, которую можно настроить через FSRM.
    7 октября 2018 г. 14:22
  • Сервер используется как хранилище пользвательских рабочих файлов. Pdf, текстовые файлы, таблицы и т.д. Win server позволяет удобно делать smb шару, которую можно настроить через FSRM.

    Добрый День.

    Можно два сервера в кластер и схд, по дедубликации и горячим и холодным данным (их распределение на разные типы носителей) в зависимости от производителя.  и приобретенной лицензии.

    Если ходите отказо устойчивое схд, то берем два схд и зеркалируем их, возможно потребуется приобретение лицензии на данный функционал


    Я не волшебник, я только учусь MCP CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Пометить как ответ" или проголосовать "полезное сообщение". Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub.

    7 октября 2018 г. 15:21
  • Антон, не понял что значит "схд, по дедубликации и горячим и холодным данным (их распределение на разные типы носителей) в зависимости от производителя".

    В идеале хочется чтобы было два сервера в кластере, к которым будет подключаться общий диск. Это нужно для того, чтобы при выходе из строя одного из серверов, пользователя перекинуло на второй абсолютно незаметно, даже если у пользователя в момент возникновения проблемы открыт какой-нибудь файл.
    Такую отказоустойчивость предоставляет transparent failover в SMB 3.0. Но, как я уже писал выше, при использовании в качестве общего диска cluster shared volume пропадает возможность использовать дедупликацию (как я понял, её можно включить только если CSV выделяется для VDI) и FSRM. При использовании других технологий нужно на каждый сервер кластера выделять одинаковое количество ресурсов хранилища.

    В общем, я просто хотел убедиться правильно ли я понял что без дополнительных затрат реализовать то, что хочет начальство, невозможно? Или есть какие-нибудь еще технологии, которые я упустил?


    7 октября 2018 г. 16:13
  • Сервер используется как хранилище пользвательских рабочих файлов. Pdf, текстовые файлы, таблицы и т.д. Win server позволяет удобно делать smb шару, которую можно настроить через FSRM.

    многие из упомянутых вами решений не подходят под пользовательские данные. Например на csv нормально работают огромные файлы дисков виртуальных машин или sql базы, ко как только сотня пользователей начнет читать/писать мелкие jpg/pdf/txt так сразу появятся дикие фризы. 

    Поэтому я бы сказал что оптимальным путем было бы дробление ресурса и презентация его через dfs на разных серверах. В такой схеме вы получите и все плюшки fsrm, и 0 издержки на дополнительный сторажд, и в случае выхода одного сервера из строя, часть ресурсов останется доступной, пока вы будете восстанавливать вторую часть.

    + если данные на сторажде не пострадали вы можете просто переподключить лун от упавшего сервера на новый и не заниматься восстановлением бекапа.


    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа Валера2 7 октября 2018 г. 18:32
    7 октября 2018 г. 16:15
    Модератор
  • Спасибо за ответ, можете только еще немного поподробнее рассказать про CSV? Я про него почитал, но так и не понял почему он будет тормозить при использовании для файлового хранилища. Вот сейчас все операции выполняет один сервер, при использовании csv все те же операции так же будет выполнять один сервер.

    По DFS, похоже это самый правильный вариант. Особенно с учетом того, что при необходимости масштабирования файлового хранилища можно будет избежать простоев. 

    7 октября 2018 г. 17:02
  • фишка csv в том что к нему можно обращаться со всех нод кластера и читать/писать можно так же со всех нод, но владельцем диска в момент времени будет лишь одна нода и она отвечает за операции записи. В итоге если у вас есть 1 vhdx на 1ТБ и внутри этого 1ТБ будут происходить операции - нода-владелец не будет учавствовать в операциях.

    В случае если у вас файлов много и пользюки их активно создают и удаляют (как бывает на файл серверах) то нода владелец вынуждена делать каждый раз вычислиние возможности запрошенной операции и их подтверждать/отклонять.

    Сделано это для того что бы 2 ноды одновременно не смогли записать порцию данных в одну и туже область диска.

    К слову сказать хранилище должно поддерживать эту возможность (persistance reservation).


    The opinion expressed by me is not an official position of Microsoft

    7 октября 2018 г. 18:11
    Модератор
  • Это понятно, я к тому, что если сервер сейчас не тормозит при всех обращениях пользователей, то и при использовании csv ничего не должно измениться в плане скорости обработки. Вот если бы у нас было 3 отдельных сервера в dfs, которые бы работали на пределе своих возможностей, то переключение на csv точно бы привело к перегрузке. Верно?
    7 октября 2018 г. 18:32
  • Это понятно, я к тому, что если сервер сейчас не тормозит при всех обращениях пользователей, то и при использовании csv ничего не должно измениться в плане скорости обработки. Вот если бы у нас было 3 отдельных сервера в dfs, которые бы работали на пределе своих возможностей, то переключение на csv точно бы привело к перегрузке. Верно?
    не уверен что слово перегрузка тут уместно но суть такова

    The opinion expressed by me is not an official position of Microsoft

    7 октября 2018 г. 19:08
    Модератор