Вопросы Теги

Неожиданное пространство RAID наверху

Ну, я не означаю просто заявлять, что очевидное, но общее представление должно продвинуть эту сложность на службы, организованные Amazon.

Таким образом на frontend, Вы использовали бы Эластичное выравнивание нагрузки (ELB) Amazon для обеспечения высоконадежного выравнивания нагрузки. На задней части Вы используете Сервис Реляционной базы данных Amazon (размещенный MySQL), SimpleDB и S3 для устройства хранения данных. Всеми ими управляет Amazon и содержат своего рода высокую доступность / обработка обработки отказа.

Это обычно оставляет Ваши серверы веб-приложения и любые меньшие общие типы сервера, которые Вы могли бы использовать (рендеринг серверов, сам установил хранилища данных NoSQL, и т.д.).

Серверы веб-приложения обычно обрабатываются достаточно хорошо с проверками состояния, встроенными в ELB. Можно принять маленькое снижение производительности, когда один сервер веб-приложения снижается, или последовательно сервер условия +1 больше, чем Вам нужно. Или если Ваша конфигурация проста, то, когда сервер веб-приложения перестал работать, ELB вместе с Cloudwatch может автоматически породить новый сервер веб-приложения для Вас.

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

Покупка решения Rightscale могла бы быть слишком дорогой. Но меньшие дорогие инструменты Amazon, такие как ELB, основное предупреждение CloudWatch (теперь свободный для разрешения 5 минут), или AutoScale определенно стоят того при необходимости в высокой доступности.

2
задан 26 January 2013 в 23:44
1 ответ

Я бы особо не беспокоился об этом. Что есть, то есть. Вы не можете это изменить. Планируйте соответственно.

Вы заметили разницу между гигабайтом и гибибайтом . 

(1024 x 1024 x 1024) = 1,073,741,824 bytes
(1000 x 1000 x 1000) = 1,000,000,000 bytes

To convert from GB to GiB, divide by 1.073741824.

Это объясняет разницу в размере диска.

Вот 6-дисковый массив RAID 1 + 0, состоящий из 300 ГБ SAS диски на контроллере Smart Array P410. Вместо 900 ГБ полезного пространства это 838 ГБ: 

  Logical Drive: 1
     Size: 838.1 GB
     Fault Tolerance: RAID 1+0
     Array Accelerator: Enabled
     Disk Name: /dev/cciss/c0d0

     Mirror Group 0:
        physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
        physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, OK)
        physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
     Mirror Group 1:
        physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
        physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
        physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)

Однако те же самые диски при запуске в системе Nexenta / ZFS с контроллерами LSI SAS показывают следующее во время форматирования: 

   7. c10t5000C5001A9EC14Fd0 <HP-EG0300FAWHV-HPDE-279.40GB>
      /scsi_vhci/disk@g5000c5001a9ec14f
   8. c10t5000C500339A0D17d0 <HP-EG0300FAWHV-HPDE-279.40GB>
      /scsi_vhci/disk@g5000c500339a0d17
   9. c10t5000C500339A1B7Fd0 <HP-EG0300FAWHV-HPDE-279.40GB>
      /scsi_vhci/disk@g5000c500339a1b7f

Так что я действительно работаю с дисками 279,4 ГБ . (3 x 279,4) = 838,2 ГБ , что близко к 838,1 ГБ доступному пространству, предоставленному на логическом диске на основе Smart Array.

Выполнение той же проверки для диска 146 ГБ на одном из моих В системах ZFS диски регистрируются как: 

  1. c17t5000CCA00A1A15BDd0 <HP-DG0146FARVU-HPDD-136.73GB>
     /pci@0,0/pci8086,3410@9/pci1000,3020@0/iport@10/disk@w5000cca00a1a15bd,0

Итак, 136,73 ГБ. (6 х 136,73) = 820.

2
ответ дан 3 December 2019 в 11:49

Теги

Похожие вопросы