Диск SQL Server разрабатывает на ISCSI SAN
В его основе SMTP является просто основанным на тексте протоколом без реальной проверки. Вот пример:
=== Trying g3.example.net:25...
=== Connected to g3.example.net.
<- 220 home.example.net ESMTP Exim 4.68 Thu, 07 May 2009 11:03:21 -0400
-> EHLO g3.example.net
<- 250-home.example.net Hello g3.example.net [192.168.0.4]
<- 250-SIZE 52428800
<- 250-PIPELINING
<- 250-AUTH CRAM-SHA1 CRAM-MD5 MSN
<- 250-STARTTLS
<- 250 HELP
-> MAIL FROM:<jj33@g3.example.net>
<- 250 OK
-> RCPT TO:<jj33@g3.example.net>
<- 250 Accepted
-> DATA
<- 354 Enter message, ending with "." on a line by itself
-> Date: Thu, 07 May 2009 11:03:21 -0400
-> To: jj33@g3.example.net
-> From: jj33@g3.example.net
-> Subject: test Thu, 07 May 2009 11:03:21 -0400
-> X-Mailer: swaks v20070921.0-dev jetmore.org/john/code/#swaks
->
-> This is a test mailing
->
-> .
<- 250 OK id=KJA4HL-0006M6-8T
-> QUIT
<- 221 home.example.net closing connection
=== Connection closed with remote host.
"ПОЧТА ОТ": строка определяет отправителя конверта SMTP, и От: определяется в сообщении ДАННЫЕ. Существуют способы защитить от этого, но они определяются в логике почтового сервера, не в самом протоколе.
Например, я, как поставщик почтовых услуг, могу потребовать, чтобы пользователь для аутентификации использования user@domain ввел имя пользователя. Затем мой почтовый сервер мог бы потребовать, чтобы любая почта, которую они отправляют, имела отправителя конверта и От: заголовок, который соответствует пользователю, которого они аутентифицировали как. Дополнительные технологии как DKIM и SPF могут помочь в этой области также.
Журналы и диски данных имеют различные шаблоны доступа к данным, которые находятся в конфликте друг с другом (по крайней мере, в теории), когда они совместно используют диск.
Записи журнала
Доступ журнала состоит из очень большого количества маленьких последовательных записей. Несколько упрощенно журналы DB являются кольцевыми буферами, содержащими список инструкций выписать элементы данных к конкретным местоположениям на диске. Схема доступа состоит из большого количества маленьких последовательных записей, которые, как должны гарантировать, завершатся - таким образом, они будут выписаны к диску.
Идеально, журналы должны идти тихое (т.е. не совместно использованные с чем-либо еще) RAID-1 или объем RAID-10. Логически, можно просмотреть процесс как основной DBMS, выписывающий записи в журнале и один или несколько потоков читателя журнала, которые используют журналы и выписывают изменения в дисках данных (на практике, процесс оптимизирован так, чтобы записи данных были сразу выписаны где возможный). Если существует другой трафик в дисках журнала, головы перемещены этими другими доступами, и последовательные записи журнала становятся случайными записями журнала. Они намного медленнее, таким образом, занятые диски журнала могут создать горячую точку, которая действует как узкое место в целой системе.
Записи данных
(обновленные) записи Журнала должны посвятить себя диску (называемый стабильными медиа), чтобы транзакция была допустима и имела право фиксировать. Можно логически просмотреть это как записанные записи в журнале и затем используемые в качестве инструкций выписать страницы данных к диску асинхронным процессом. На практике дисковые записи страницы на самом деле подготовлены и буферизованы в то время, когда запись в журнале сделана, но они не должны быть сразу записаны, чтобы транзакция фиксировалась. Дисковые буферы выписаны к стабильным медиа (диск) Ленивым процессом Устройства записи (Благодаря Paul Randal для указания на это), который статья This Technet обсуждает в немного большем количестве деталей.
Это - шаблон в большой степени произвольного доступа, так совместное использование тех же физических дисков с журналами может создать искусственное узкое место на производительности системы. Записи в журнале должны быть записаны, чтобы транзакция фиксировала, таким образом имение случайного ищет замедление этого процесса (случайный ввод-вывод намного медленнее, чем последовательный журнал ввод-вывод), повернет журнал из sequenital в устройство произвольного доступа. Это создает серьезное узкое место производительности в занятой системе и должно избежаться. То же применяется при совместном использовании временных областей с объемами журнала.
Роль кэширования
Контроллеры SAN имеют тенденцию иметь большие кэши RAM, которые могут поглотить трафик произвольного доступа до некоторой степени. Однако для целостности транзакций желательно иметь записи на диск от DBMS, который, как гарантируют, будет завершаться. Когда контроллер установлен использовать кэширование обратной записи, грязные блоки кэшируются, и о вызове ввода-вывода сообщают как завершенном хосту.
Это может сгладить много состязательных проблем, поскольку кэш может поглотить много ввода-вывода, который иначе вышел бы в физический диск. Это может также оптимизировать чтения четности и записи для RAID-5, который уменьшает эффект на производительность, которую имеет RAID 5 объемов.
Это характеристики, которые управляют 'Позволенный соглашение SAN с ним' философская школа, хотя это представление имеет некоторые ограничения:
Обратная запись, кэширующаяся все еще, имеет виды отказа, которые могут потерять данные, и контроллер выдумал к DBMS, блоки высказывания были выписаны к диску, где на самом деле они не имеют. Поэтому Вы не можете хотеть использовать обратную запись, кэширующуюся для транзакционного приложения, particlarly что-то содержащее важнейшие или финансовые данные, где проблемы целостности данных могли иметь серьезные последствия для бизнеса.
SQL Server (в особенности) использует ввод-вывод в режиме, где флаг (названный FUA или Принудительным Доступом Обновления) вызывает физические записи к диску перед возвратами вызова. Microsoft имеет программу сертификации, и многие поставщики SAN производят аппаратные средства, которые соблюдают их семантика (требования, полученные в итоге здесь). В этом случае никакая сумма кэша не оптимизирует записи на диск, что означает, что трафик журнала перегрузится, если он будет находиться на занятом совместно используемом томе.
Если приложение генерирует большой дисковый трафик, его рабочий набор может превысить кэш, который также вызовет проблемы конкуренции записи.
Если SAN совместно используется с другими приложениями (особенно на том же дисковом томе), трафик из других приложений может генерировать узкие места журнала.
Некоторые приложения (например, хранилища данных) генерируют большие переходные скачки загрузки, которые делают их довольно антиобщественными на SAN.
Даже на большом SAN отдельные объемы журнала являются все еще методическими рекомендациями. Можно сойти с рук не worring о расположении на слегка используемом приложении. На действительно крупных приложениях можно даже извлечь пользу из нескольких контроллеров SAN. Oracle публикует ряд тематических исследований расположения хранилища данных, где некоторые большие конфигурации включают несколько контроллеров.
Поместите ответственность за производительность, где она принадлежит
На чем-то с большими объемами или где производительность могла быть проблемой, сделайте команду SAN ответственной за производительность приложения. Если они собираются проигнорировать Ваши рекомендации для конфигурации, то удостоверьтесь, что управление знает об этом и что ответственность за производительность системы находится в соответствующем месте. В частности, установите приемлемые инструкции для ключевой статистики производительности DB как ввод-вывод, ожидает, или фиксатор страницы ожидает или приемлемое приложение SLA ввода-вывода.
Обратите внимание, что нести ответственность за разделение производительности через несколько команд создает стимул к точке пальца, и переложите ответственность на другую команду. Это - известный антишаблон управления и формула для проблем, которые вытаскивают в течение многих месяцев или лет без того, чтобы когда-нибудь быть разрешенным. Идеально, должен быть единственный архитектор с полномочиями для определения приложения, базы данных и изменений конфигурации SAN.
Кроме того, сравните системы при загрузке. Если можно расположить его, подержанные серверы и массивы прямого присоединения могут быть куплены вполне дешево на eBay. При установке поля как это с одним или двумя дисковыми массивами, можно трахнуть с конфигурацией физического диска и измерить эффект на производительность.
Как пример, я сделал сравнение между приложением, работающим на большом SAN (IBM Shark) и полем с двумя сокетами с прямым присоединением массив U320. В этом случае ценность за 3 000£ аппаратных средств, купленных от eBay, превзошла высокопроизводительный SAN за £1 миллион по характеристикам фактором два - на хосте примерно с эквивалентным ЦП и конфигурацией памяти.
От этого конкретного инцидента можно было бы утверждать, что наличие чего-то вроде этого лежащего вокруг является очень хорошим способом сохранить администраторов SAN честными.
-
1Это cut' n' вставка или ЛУЧШИЙ ОТВЕТ КОГДА-ЛИБО НА SERVERFAULT!!!!!!:) – Chopper3 15 May 2009 в 13:35
-
2Нет, I' m просто быстрая машинистка;-} – ConcernedOfTunbridgeWells 15 May 2009 в 17:02
-
3Вы - человек. – squillman 15 May 2009 в 19:01
-
4Просто произошедший для чтения этого из ссылки Вы вставляете другой ответ. Эта часть Вас ответ является неправильным " Элементы данных записаны в диски данных читателем журнала. Это использует записи в журнале и выписывает элементы данных к диску " записи Страницы данных выполняются контрольной точкой и процессами ленивого устройства записи в пуле буферов, и не имеют ничего вообще, чтобы сделать с процессами читателя журнала. Записи страницы данных также не генерируют записи журнала. – Paul Randal 24 June 2009 в 21:49
-
5Хорошо определенный. I' ve обновил статью для фиксации его. – ConcernedOfTunbridgeWells 25 June 2009 в 13:59
Большой вопрос!
Сначала смотрите на "Steel Cage Brent Ozar BlogMatch" дебаты по этой проблеме.
В нашей компании, для большинства серверов, мы помещаем Данные и Вход в систему тот же диск SAN, и оставляем его до команды SAN, чтобы удостовериться, что все работает правильно.
Я начинаю думать, что это не лучшая стратегия, специально для серверов более высокого объема. Базовая проблема состоит в том, что у меня действительно нет способа проверить, что команда SAN действительно делает что-то большее чем хлопает вместе достаточно дисков для пространства, в котором мы нуждаемся. Мы не выполняем сравнительные тесты IO против дисков SAN с нашей стороны или чего-либо, мы отчасти просто предполагаем, что они "делают свое задание" (корректирующийся для производительности, а также пространства), который, вероятно, немного наивен.
Моя другая мысль - то, что вид доступа, в котором нуждаются данные по сравнению с журналами, отличается. Я попытаюсь найти статью, я недавно считал, что говорил о том, как два различных типа дисков действительно должны быть оптимизированы совсем другими способами (я думаю, что тому были нужны оптимизация для последовательных записей, другая необходимая оптимизация для случайных чтений, чего-то как этот.)
Я согласился бы с BradC (+1) с точки зрения производительности. Обычно хороший SAN имел бы больше необработанного ввода-вывода, чем Вы могли ожидать использовать.
Это - все еще хорошая идея выделить Ваши РЕЗЕРВНЫЕ КОПИИ от Вашей живой системы (Очевидный, что я знаю, но если у меня был 1£ в течение каждого раза, когда я вижу это...),
Кроме того, держание отдельно tempdb от файлов журнала рекомендуется. Палатка парня SAN для выпучивания их глаз на Вас, когда Вы начинаете желать "различные блоки" (технический термин) для Журналов, Данных и Временного файла, но если Вы говорите им, это - так Вы, может измерить другой объем данных IO, идущий в каждую область, и заставить их показывать Вам свои необычные графики производительности!
Просто удвойте/проверьте это дважды, парень SAN установил его прямо для Вас. Если Вы хотите RAID 10, затем настаивают на нем (я сделал) даже при том, что они продолжали говорить, что их RAID 5 не имеет никакой потери производительности.
(Поскольку "файл основывал" операции, RAID 5 прекрасен. Для интенсивных записей, как только Вы заполняете буфер записи Ваш завинченный!)
-
1+1 для социальной инженерии компьютерные фанаты устройства хранения данных. – pboin 23 October 2009 в 17:48
Мы храним наш DBS на единственных полях SAN, но с отдельными данными, журналом и копируем LUN, у каждого на различных группах дисков, разделенных на уровни скоростью - с, есть наши LUN RAID 10 15Krpm входа в систему, данные по LUN RAID 1 10/15krpm и резервному копированию на LUN RAID 5 7.2krpm. Мы также представляем журналы и данные через различные контроллеры на том же SAN.
Короче говоря, да, Вы создали бы отдельные объемы для файлов данных SQL Server, файлов журнала, и файлов данных TempDB и файлов журнала.
Так как Вы отметили свой вопрос с Equallogic, прочитайте бесплатное Руководство по эталонным архитектурам Dell: Развертывание Microsoft® SQL Server® с Серийными Массивами хранения данных Dell™ EqualLogic™ PS5000 (требуемая регистрация) прежде, чем разработать Ваше решение. Часто Вы будете находить, что руководство на определенных конфигурациях может значительно отличаться от универсального совета.
Я предполагаю, что тег Equallogic и содержание запроса означают, что Вы говорите о SAN Equallogic. То, что следует, конкретно о Equallogic, и он не относится к другим типам SAN.
С массивами Equallogic определенные диски, используемые для объемов, не могут быть указаны так точно, как они могут с, скажем, массивами EMC Clariion, таким образом, подход должен несколько отличаться.
Архитектура Equallogic очень автоматизирована и динамичная. Его основа является единицей массива не RAID packs\groups в массиве, как замечено в других SAN. Каждый массив полностью настроен для RAID 5, 6, 10 или 50, хотя это не подразумевает, что существует только одна группа RAID на массив, Вы просто никогда не добираетесь, чтобы решить или взаимодействовать с ними на том уровне. Вы помещаете массивы в Пулы хранения данных, и Ваши объединения затем принадлежат Группе устройств хранения. Группа устройств хранения имеет cluster\virtual IP-адрес, который Вы используете в качестве цели Исследования iSCSI для всех объемов в той группе - программное обеспечение управления EQL Group и размещаете дескрипторы стека MPIO, которые уровень IP rediredection должен был на самом деле направить к самому соответствующему порту на отдельных массивах при запросе блоков данных, но это - что-то, чем у Вас есть минимальная способность управлять.
Тома присвоены от общего свободного пространства в каждом пуле. Все объемы в пуле распространены через все массивы в том пуле (хорошо до макс. из 4 отдельных массивов) для распределения сети IO через общее количество сетевых интерфейсов (2-4 на массив Eql в зависимости от модели) и IO через как можно больше контроллеров. Программное обеспечение управления Equallogic контролирует volume\array производительность со временем и динамично оптимизирует распределение блоков через членские массивы. В целом, если Вы не знаете то, что Вы делаете, необходимо поместить все массивы в единственный пул и позволить ему сделать, его вещь просто не забывает гарантировать, чтобы Вы настроили свои высокоскоростные диски (SAS 10k\15k) с RAID 10, средней скоростью с RAID 50 или 5, чтобы удостовериться, что процесс оптимизации на самом деле выбирает очень высокие высокопроизводительные диски. Может потребоваться довольно много дней (7 +) для фактического получения до оптимального состояния, но в целом это должно поразить сбалансированное распределение довольно быстро, поскольку это сразу распределяет объемы по стольким массивам, сколько это может (снова до 4), когда они первоначально создаются.
К грубому приближению Вы будете иметь где-нибудь между 2500-5000 IOPs на массив пз в зависимости от типа RAID и типа дисков. При обеспечении достаточного количества общего IOPs затем, процесс автоматизированного управления должен в конечном счете дать Вам хорошую производительность даже если Вы просто глыба все объемы в единственный пул.
Однако, если Вы хотите гарантировать, что Ваши журналы, базы данных, временные хранилища, диски ОС и т.д. на самом деле изолируются друг от друга, можно сделать несколько вещей. Во-первых можно определить предпочтение RAID объема, который гарантирует, что удельный объем всегда хранится только на массивах того, что тип RAID (если они присутствуют в пуле объем, принадлежит). Во-вторых, можно определить пулы многоуровневого хранения, которые только содержат массивы, которые обеспечивают различные классы производительности, которой Вы требуете для того конкретного уровня и затем распределяете свои объемы в соответствующие пулы. Предупреждение о вреде для здоровья, которое идет с этим подходом, - то, что Вам обычно будет нужно много массивов для этого для фактического обеспечения лучшей общей производительности - который может быть менее важен для Вас, чем гарантия производительности на Ваших критических объемах хотя, таким образом, это - часто все еще лучший выбор. Эталонная архитектура Dell для использования DB Oracle один пул с 2 массивами RAID 10 для Данных, Голосуя за диск и OCR и отдельный пул с единственным RAID 5 выстраивает для области Восстановления Flash.
Во всех моментах времени с Equallogic необходимо спросить себя, если решения, которые Вы принимаете относительно вынужденного разделения, собираются обеспечить лучшую совокупную производительность для Ваших объемов с точки зрения доступных сетевых интерфейсов, шпинделей диска и контроллеров. Если Вы не можете ответить, что затем выбирают минимальное количество пулов и оставляют его, обрабатывают детали или приводят специалиста Equallogic, чтобы сделать реальный дизайн. Если у Вас только есть один массив затем нет ничего, что можно сделать с точки зрения разделения объемов.
Знайте обо всем смешивании условий здесь также..
Обычно и очень простой:
- Массив = пул дисков в установке RAID (как RAID5)
- Объем = часть массива, представленного хосту на SAN с LUN
У Вас может быть несколько объемов на том же массиве, который является чем-то для запоминания, когда Вы делаете оптимизацию высокого качества, обсужденную в этом потоке.
Ключ - то, что несколько других упомянули (не забывайте это), разделите данные/журнал/резервное копирование по различным шпинделям диска, не только отдельные объемы.
Править: и Helvick выше дал Вам - большой ответ о SAN Equallogic!