Очевидно, что существует бесконечное множество способов разделить ваши необработанные логические модули SAN для обеспечения загрузки виртуальных машин и виртуальных дисков данных - но какие методы вы используете, каковы их плюсы и минусы, и есть ли у вас какие-либо хорошие `` передовые практики ''. встречаются (кроме очень общих VMWare, я имею в виду). Заранее спасибо.
Как вы уже догадались, это не вопрос VMware, а вопрос SAN. TR-3428 и его двоюродный брат по VDI TR-3705 отлично справляются с описанием реализации VMware в NetApp SAN. Использование этих документов в сетях SAN, отличных от netapp, является спорным. Поскольку они не учитывают какие-либо сильные / слабые стороны вашего SAN. Сказав это, мои взгляды по этому поводу.
Есть много причин разбить ваши хранилища данных. Самая распространенная причина ESX3.5 - это, без сомнения, блокировка. Некоторые предпочитают иметь хранилища данных ОС / загрузки и хранилища данных приложений, но я обнаружил, что любое повышение производительности, которое это может дать, незначительно. Я видел реальное повышение производительности за счет выделения временных данных из ОС в отдельное хранилище данных, но для того, чтобы этот метод был жизнеспособным, вы должны перенаправить в хранилище данных с высокой производительностью.
В конце концов, я вернулся к одному vmdk на vm и обрабатывал исключения. Я сделал это по двум причинам. Во-первых, я нашел лучшая практика реализация была слишком сложной. Мало того, что это было сложно установить, но часто системная SA проваливала, сводя на нет любую возможную выгоду. Часто снижает производительность виртуальной машины. Во-вторых, с sVMotion сегодня это действительно не так важно, как раньше. Раньше нужно было знать все ответы. в настоящее время просто сделайте качели, если вам нравятся результаты, и дальше в этом направлении. ВМ - это нарлейские животные, и никакие две виртуальные инфраструктуры не похожи друг на друга. Поэтому лучшие практики имеют ограниченное использование. Метод проб и ошибок в конечном итоге предоставит вам лучшее решение в вашей среде.
При этом я использую NetApp поверх NFS (с дедупликацией (В ПРОИЗВОДСТВЕ)) и запускаю хранилище данных на 600 ГБ, в котором в среднем 60 виртуальных машин .... Для меня коэффициенты консолидации, предлагаемые NFS, перевешивают снижение производительности. Несколько (менее 10) виртуальных машин, которыми я управляю, требуют большего, чем может предложить NFS, размещаются в хранилище данных ISCSI (250 ГБ).
Там, где я работаю, мы представляли LUN с оптоволоконным подключением к серверам ESX размером 500 ГБ. Из-за проблем с резервированием SCSI кажется, что 500 ГБ - оптимальный размер для предоставления хранилища, подключенного к FC, для ESX.
Возникает большая тенденция - использовать хранилище, подключенное к NFS, для ваших хранилищ данных ESX, особенно сейчас, когда Ethernet 10 Гбит / с становится популярным. NFS предоставляет множество преимуществ по сравнению с традиционными хранилищами с оптоволоконным подключением, а также в среде ESX.
Было бы полезно узнать, какой тип хранилища вы используете, поскольку разные хранилища имеют разные функции и параметры, которые можно использовать в средах VMware.
Очень информативное руководство, которое я довольно часто использовал в прошлом, если вы используете хранилище NetApp, это TR-3428. Он также содержит некоторую общую информацию о ESX / SAN, которая может быть полезна, если вы пользуетесь хранилищем другого поставщика.