EC2 - Спільне зберігання - S3FS або EBS?


9

Побудова мого веб-сервісу зараз на EC2 і мати єдиний екземпляр поза балансиром навантаження. Я, звичайно, буду задовольняти кілька випадків.

Моя початкова ідея полягала в тому, щоб запустити всі екземпляри тупих рабів і використовувати S3 в якості локального сховища. Для цього я почав використовувати S3FS, але він, з того, що я бачив, не готовий для використання у виробничих умовах в Інтернеті. Написання журналів, здається, з’являється дуже пізно, якщо ніколи. Численні проблеми з незвичайним кешуванням, навіть без кеш-прапорів тощо. Просто загалом кошмар, який потрібно розвивати.

Але альтернатив виглядає мало. Очевидно, що томи EBS, які можна приєднати до одного екземпляра. Деякі рішення для спільного використання цього:

  • Обмін SMB для інших примірників. Маючи одного хазяїна та решти невільників - можливо, тут потрібні надмірності, вбудовані тут з кількома томами EBS?
  • Rsync-доступ до інших вікон. Це здається болісним, вважаючи його не стійким і періодично оновлюватиметься. Потенційно добре, якщо примушують сценарії оновлюватись, коли відбулися основні зміни.

Питання ... що роблять люди? Це здається цілком розповсюдженим випадком використання, але різноманітність відповідей, знайдених на форумах і навіть тут на SF, начебто говорить про те, що немає чіткої відповіді ... допомога потрібна!

Відповіді:


0

Це тому, що відповідей існує багато, залежно від ознайомлення з параметрами, чим вам зручно, чим ви ділитесь і як часто це потрібно синхронізувати, наскільки "синхронізовано" це потрібно, як вони " Ви будете використані (запасні для серцебиття? Читати лише проти екземпляра запису? Збалансовані екземпляри?) та наскільки складною ви хочете налаштування та який додаток ви використовуєте (бази даних, які можуть синхронізувати себе? Програми, створені для спільного зберігання ? ...)

Ви можете використовувати Rsync для планування синхронізації, спільного доступу з файлового сервера, сервера NFS, DRBD "програмного RAID 1" тощо ... це залежить від конкретного випадку використання та способу резервного копіювання даних.

Коротка відповідь - немає відповіді на ваше запитання, оскільки це залежить від випадку використання.


Дякую Барту. Я побоювався такої відповіді, хоча, мабуть, слід було очікувати! Випадок використання ... У мене є веб-сервіс, керований PHP - він також розміщує зображення, css та інше (все це може бути перенесено на стандартний s3 / cloudfront), БД є на RDS. Єдине, що написано - це файли журналів, які насправді минули. - Я рухаюсь до використання EBS з rsync для того, щоб вона була в курсі s3. І сценарій для натискання оновлень вручну.
восковий

2

Обсяг EBS, який підштовхується до S3 / CloudFront, здається, найкращим кроком тут, особливо якщо ви турбуєтесь про зображення, CSS, javascript, подібний тип матеріалів.

EBS буде легше робити знімок / резервне копіювання, ніж S3, особливо для файлової системи сервера.

Ви також можете призначити один сервер як "ведучий", а інший - як "підлеглий", і лише вносити зміни в "головний", наприклад.

Що стосується ведення журналів, перегляньте деякі служби хмарного ведення журналів, такі як http://loggly.com/ або https://papertrailapp.com/ .

HTH

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.