Junost,
Решается только горизонтальным масштабированием. В рамках облаков, VPS, дедиков - значения принципиального не имеет технологически, разница только в сложности обслуживания и стоимости.
Короче говоря, это не самый главный вопрос.
Начать надо с вертикальной структуры проекта - балансеры, приложение, базы данных, кешы и т.д.
Смотреть что из этого критикал и должно иметь 100% uptime. Каждый узел имеет свои особенности и уровень сложности для реализации кластеризаций и масштабирований.
Как вариант, остановиться только на кластеризации балансеров, и на их уровне делать логику а что происходит если более низкий уровень (приложения) становятся недоступными.
Балансеров должно быть тогда минимум 2, да желательно в разных регионах или площадках. Свыше это управляется одним из гео днс сервисов с проверкой живучести балансеров. Данный сервис становится по сути единой точкой отказа, поэтому это должен быть надежный сервис, с ддос защитой, распределенной географически. Хорошая новость - таких сервисов достаточно много, есть даже бесплатные.
Кластеризация более низкий узлов зависит от бизнес необходимостей (SLA) и бюджетов. А также от используемых приложений.
А выбор площадки - есть услуги более заточенные под такие действия, есть вообще не заточенные. Сделать можно на любых, как я уже сказал разница в сложности обслуживания и стоимости. Самые эффективные и дешевые - это заточенные под это облачные платформы с разными регионами.
Платят всегда, как минимум за траспорт. Но стоимость участия в exchange всегда ниже чем покупка IP Transit.
Поэтому в некоторых случаях провайдеры даже доплачивают за то, чтобы подключаться через exchange через отдельный пиринг, ибо это дешевле.
Конечно согласен, что 30 Тб в месяц это вообще не о чем.
Мы cisco не используем (кроме каких-то старых свичей для ipmi), но как бы это не проблема с точки зрения безопасности.
Если совпадает md5, sha512 и размер файла, то изменить не получится. А эти данные есть на оф сайте.
Фантазии дело хорошее, но не в законах.
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
Расскажите мне, как фотка хомячка, или допустим логин ftp поможет мне идентифицировать конкретное физическое лицо?
Не то выделили болдом. Нужно слово приблизительно, и детали. ну да ладно.
Ваш ответ понятен, он несомненно имеет право на жизнь, но только не в тех условиях, про которые я писал речь (те самые, которые Вы выделяли болдом).
То что на мой взгляд может иметь право на жизнь это вынесение таких данных в отдельную форму, и данные из этой формы могут и должны удаляться, причем автоматически. Это могут быть пароли, ключи, любая информация имеющая отношение к безопасности.---------- Добавлено 02.09.2018 в 12:08 ----------
GDPR о персональных данных, а не о деталях и истории заказа. Аналогично и фз 152.
А то таким образом можно прийти скажем к поставщику электроэнергии и запросить его удалить данные потребления (счетчика), аргументируя что это частные данные, и соседка обсуждают как много тратится электроэнергии, а откуда она еще может узнать эти данные, только от поставщика, у них же данные есть.
Или попробуйте запросить удаление данных у тех же ОПСосов, дескать я уже перешел к другому, удаляйте сколько и что я использовал и платил. Good Luck. И это я не говорю про обязательства со стороны закона хранить эту информацию.---------- Добавлено 02.09.2018 в 12:13 ----------
Нет, не четко. Фотка хомячка и паспортные данные - это разные вещи согласно закону.
Ну справедливости ради, goldhost это один из первых хостеров и регистраторов доменов в рунете. Старожили этих ребят знают. Я у них покупал свои первые домены в начале 2000, или даже конце 90.
Поэтому тут или они забили на свою судьбу (что в принципе подтверждает опосредованно дизайн и наполнение сайта) или какие-то тех проблемы с получением почты / коммуникации.
edogs,
А можно Вас попросить, вот Вы поставьте себя на место хостинг компании, приблизительно прикинув юридические обязательства (которых дофига и они очень размыты и противоречивы в плане хранения данных по всяким новомодным законам), служебные обязательства (контроль сотрудников, организация работы разных отделов или даже разных групп в разных офисах), а также, что возможно самое главное в конечном итоге - обязательства репутации, как Вы правильно написали, "не быть мудаком".
Прилетает подобный запрос - удалите такие-то данные из моих обращений. Ваши действия?
Я сейчас не говорю про юридические детали или какие-то внутренние процедуры и правила. Скорее понять как Вы бы видели это, как на Ваш взгляд было бы правильно.
И кстати, уточните еще раз, Вы вроде бы писали сначала про служебные данные (т.е. как я понимаю, например, данные доступа, или те же SSL сертификаты, ftp логины). Но периодически пишите про паспортные данные и приватные данные. Это все же разные вещи.
Несколько соображений в неформальной форме ответа ;)
1. Можно, более того - нужно, после завершения таких работ данные доступа менять. Это обязательная практика, которую просто даже можно и не упоминать.
Это решает в принципе вопросы, и вопрос доверия, и вопрос возможных взломов, в том числе и у тех у кого есть доступы и т.д.
Пример: мы также передаем периодически данные доступа как хостер некоторым компаниям-разработчикам, например, cPanel, Virtuozzo, CloudLinux. И везде красными буквами написано, что обязательно меняйте доступы. Это аксиома.
2. Касательно самого вопроса. По GDPR контроллер данных обязан удалить персональные данные по запросу. Но в Вашем случае это не персональные данные, а служебные данные для выполнения заказа. Вот смотрите, мы удалили данные, на след. день Вы пишите, на каком основании мне был выставлен такой-то счет. Или вот собственно то что Вы и написали, меня взломали, это вы виноваты. Если ничего не удалено, то есть вся история, что было сделано, почему, когда и кем на месте, то вопрос решается конкретными фактами и проверками.
На мой субъективный взгляд это в интересах клиента, чтобы он был уверен, что никто и никогда не может изменить или удалить данные запросов.
ТС, ориентир Вам дали. На Вашем месте обратите внимание на след. нюансы:
1. Удаленные руки, что в них входит, сроки и время работы, стоимость перерасхода. Одно дело ткнуть ребут, другое дело найти сбойный модуль памяти из 16 штук.
2. Наличие стока оборудования. В коммерческих дц стока оборудования для клиентов не держат.
2.Б Есть ли у дц/хостера хорошие контакты с дистрибьюторами, чтобы он вам мог заказать без геммороя для вас что-нибудь на замену/апгрейд. И захочет ли он этим заниматься и за какие деньги.
3. Вопрос абуз. Коммерческие датацентры, не ориентированные на хостеров а ориентированные на бизнес имеют сложности с пониманием вопрос абуз, ибо на бизнес клиентов абузы не приходят либо это что-то из ряда вон выходящее. Я уже тут рассказывал историю лет 10 назад как нас выперли из одного дц в НЛ где мы стояли с одной стойкой всего навсего за 2 абуза за год на уровне spamcop.
4. Ну и наверно последнее, но не по значимости - документальное оформление и просто ощущение доверия. Идти куда-то где дали на 10 евро дешевле и потом остаться с проблемами - такое случается запросто, и не только на Украине ;)
Если оплата идет через вас, то я предполагаю что у вас уже есть какая-то бухгалтерия и ЛК. Тогда Вам в этой ситуации ставить отдельный биллинг под хостинг смысла не имеет.
Если же нужен отдельный биллинг под хостинг, то это уже путь к тысячи и одной проблеме: нужно и всевозможным ФЗ соответствовать (хранение ПД, прием оплат, если от физ лиц то кассы) и т.д. Это отдельный бизнес.
Из того что Вы написали, Вы веб-студия / девелоперы. Вот и продавайте эти услуги. А хостинг как сопутствующая услуга, без дополнительных тарифов и биллингов.
Технически, проще всего взять именно реселлер хостинг на базе виртуального хостинга. Это будет администрироваться хостером, бэкапы, обслуживание, закрытие дырок, лицензии, распределение ресурсов - все на хостере.
Брать единый VPS для всех клиентов я бы не советовал, это будет дорого т.к. нужно брать с запасом по ресурсам, нужно все брать на себе по обслуживанию либо отдавать на обслуживание хостеру что будет еще дороже, запаса по ресурсам мало в случае каких-то перерасходов по ресурсам - все клиенты страдают от одного. И т.д.
Есть вариант облаков, когда каждого клиента сажают в отдельные окружения, это будет надежное решение, но вероятно не вписывающее в бюджет для сайтов визиток и избыточно. Для сайтов визиток ничего лучше виртуального хостинга нет и вряд ли будет. А вот если клиенту уже нужен нагруженный интернет магазин например, тут уже можно и смотреть.
