Архив автора: admin

Как привязать домен своего сайта к почте Яндекса или Gmail

Доброго времени суток, уважаемые читатели! Продолжаем изучать новые фишки блоггинга и заработка в интернете. Сегодня я расскажу Вам, как создать почту со своим доменом. Возможно, Вы неоднократно видели на различных сайтах, что адрес почтового ящика для связи с его владельцем выглядит примерно так admin@домен.ru Какие эмоции у Вас вызывает такой почтовый ящик? Хотели бы и Вы себе такую почту?

Зачем нужна почта для домена?

Любой блоггер может указать для связи просто свой имейл. Или установить форму обратной связи через которую письмо будет приходить на Ваш имейл, а отправитель не будет знать Вашего почтового ящика до тех пор, пока Вы ему не ответите обратным письмом.

Зачем тогда нужна почта с доменом сайта? К красивых коротких имейл адресов с годами все меньше и меньше. Чаще всего при регистрации своего первого почтового ящика мы не проявляем изобретательность, и чтобы побыстрее зарегистрировать имейл добавляем в конце циферку и все. А потом оказывается, что этот имейл бессмысленный, не несет никакой информации о его владельце. Оригинальная почта на своем домене позволяет выделить из толпы и заявить о себе. Для кампаний почта с названием сайта – это прежде всего статус. Для не коммерческого проекта почтовый ящик такого вида, подчеркнет его серьезность и статус. Как по мне, то еще один плюс такого имейла – возможность заявить о себе. К примеру, можно указать в комментарии имейл для связи и сразу будет видно, что он принадлежит владельцу сайта, домен которого, указан в нем. А это возможность привлечь дополнительных посетителей.

А как Вы считаете, есть ли польза от почты с именем сайта, или ее настройка пустая трата времени? Высказывайтесь в комментариях.

А теперь рассмотрим как привязать почту к домену. Я рассмотрю три наиболее популярные почты яндекса, гугла и майл.

Настройка почты для домена Google (Гугл)

Почта для домена google предоставляется бесплатно всего на 30 дней. Далее Вам предложат оплачивать по 5 долларов ежемесячно за использование услуги Google Apps. Если Вы не готовы к таким расходам, делайте настройку почты yandex для домена. Инструкция ниже.

Для создания почты Гугл для домена переходите по ссылке http://www.google.com/enterprise/apps/business По средине экрана Вы увидите зеленую кнопку с надписью «Начать здесь». После клика по ней откроется вот такая страничка:

Как создать почту для домена у Гугла

Заполняйте все поля формы. Придумайте свой брендовый имейл.

На следующем шаге выберите «использовать приобретенное имя»:

Как подключается почта на собственном домене

На последнем шаге регистрации укажите имя пользователя, пароль и согласитесь с правилами системы.

Регистрация почты в Google Apps

Регистрация окончена, переходите к настройкам Google Apps:

Вход в Google Apps

Первое, что Вам нужно сделать – подтвердить право собственности на домен:

Подтверждение права собственности на домен в Google Apps

Я обычно выбираю подтверждение прав через загрузку файла на хостинг, но Вы можете выбрать для себя другой способ из списка.

Куда закачать файл подтверждающий право собственности на домен

Скачиваете файл, загружаете его на папку public_html, проверяете открывается ли файл по нужному адресу и подтверждаете проверку прав собственности.

Последний этап настройки gmail почты для домена – создание MX записей для перенаправления почты на красивый почтовый ящик. Следуйте пунктам инструкции на странице гугла.

Как прописать MX записи, чтобы подключить почту к домену

Пересказывать каждый шаг не буду. Расскажу, что необходимо сделать на сайте регистратора доменного имени. У меня это 2domains. В панели управления доменом выбирайте «Управление зоной DNS». Ни в коем случае не удаляйте DNS сервера хостера, иначе сайт перестанет работать. Находите форму добавления записей:

Как настроить домен гугл почты

В ней выбирайте тип добавляемой записи MX, данные хоста, которые указаны у Google Apps и приоритет. Заполняйте все строки последовательно. После этого нажмите на кнопку добавить.

Готово!

Почта для домена Яндекс (yandex)

Yandex почта для домена пока бесплатная в отличии от Google. Говорю пока, потому что все может поменяться. Настройка почты яндекс для домена во многом схожа с рассмотренной выше гугловской почтой.

Перед тем, как подключить яндекс почту к домену нужно зарегистрировать почтовый ящик в Яндеке. Если он у Вас уже есть, просто заходите в аккаунт. Кликайте по ссылке https://pdd.yandex.ru/domains_add/ и на открывшейся странице вводите тот домен, который хотите подключить к почте Яндекса.

Как привязать домен к почте яндекса

На следующем этапе подтверждаем, что именно Вы владелец этого домена. На рабочем столе создайте текстовый документ и назовите его именно так, как хочет Яндекс. Внутрь его добавьте проверочный текст и сохраните его. Загрузите этот файл в папку public_html. Если яндекс пишет, что проверочный файл не найден, проверьте расширение загруженного файла, чтобы на конце не было .txt. Если оно присутствует — удалите его.

Делегировать домен на Яндекс не нужно!

Инструкция по настройке почты яндекс со своим доменом

На втором этапе, прописываем MX-записи у регистратора домена. Куда заходить и где их прописывать я объясняла на примере настройки Гугл почты с доменным именем Вашего сайта. Посмотрите.

Как настроить почту для домена у yandex

Не пропустите точку на конце строки mx.yandex.ru.

Привязка домена к почте яндекс - прописываем MX-записи

Если Вы все сделали правильно, через некоторое время увидите надпись «Домен подключен». Осталось указать желаемый логин почты и пароль к нему.

Настройка яндекс почты для домена

После этого войдите в почтовый ящик:

Как создать почту со своим доменом на яндексе

После первого входа заполните регистрационную форму:

Электронная почта со своим доменом

Вот собственно и все. При  желании можете подключить перенаправление писем из других почтовых ящиков на этот.

Вот так происходит подключение почты к домену. Проделав все шаги Вы получите свой красивый почтовый ящик на домене. Привязывать яндекс или гугл почту к домену выбирайте сами. Хочу только напомнить, что на данный момент яндекс почта для домена бесплатная.



2014-10-03T20:15:19
Блог на WordPress

Имбирь

Чудо-корень —  имбирь

Cуществует множество советов, домашних средств или лекарственных препаратов против головной боли, резях в желудке или от насморка. Однако не хочется немедленно прибегать к сильнодействующим лекарствам. Возможно, поможет имбирь!

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

Имбирный корень славится особым пряным и терпким ароматом, который ощущается благодаря содержащимся в нем эфирным маслам. А своим жгучим вкусом имбирный корень обязан веществу — гингеролу. В нем содержится более 150 полезных микроэлементов и витаминов. Клинически доказано, что имбирь действует как противовоспалительное и антибактериальное средство, активизирует работу желудочно-кишечного тракта.
В традиционной китайской медицине (TCM) и индийской медицине (Аюрведа) на протяжении многих веков корень имбиря используется как согревающее средство. Его применяют при простуде, в качестве болеутоляющего, он помогает справиться с укачиванием в транспорте, тошнотой и мигренью.
Современная классическая медицина лишь сравнительно недавно начала изучать целебные свойства имбиря. Последние опубликованные исследования доказывают эффективность имбирного корня при борьбе с токсикозом во время беременности, с тошнотой при укачивании, а также с рвотным рефлексом, возникающим вследствие химиотерапии. Доказано также, что с помощью препаратов из имбиря можно облегчить периодические боли у женщин, значительно уменьшить боль при артрозе и в мышцах.
Однако это далеко не полный перечень целебных свойств чудодейственного корня. Исследования на крысах показали, что имбирь способен предотвратить или замедлить развитие катаракты у больных сахарным диабетом, понизить уровень сахара в крови. Экстракт имбирного корня, а точнее, его жгучие вещества – гингеролы, ускоряют поступление глюкозы в клетки мышечных тканей, уровень которой у больных сахарным диабетом 2-го типа понижен из-за нарушения инсулиновой реакции.
Лечебные свойства имбирного корня наиболее ярко выражены при употреблении его в виде чая или так называемой «имбирной воды». Для её приготовления необходимо тонкие ломтики свежего корня настоять в течение 10 минут в горячей воде, а затем сразу выпить этот отвар. Для снятия мышечного напряжения можно принимать ванну с имбирем, прикладывать его к коже, делая «имбирное» обёртывание. Рекомендуется всем, кого укачивает в автомобиле, автобусе или самолете брать с собой в дорогу кусочек имбиря или имбирное печенье.

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

Читать →

Фаршированный перец и картофельный суп и Термомикс

​на 6 человек

Ингредиенты:

Перцы:

  • 3 болгарских перца
  • 50 г сыра Пармезана
  • 100 г ветчины
  • пучок петрушка
  • 2 кусочка черствого хлеба
  • 100 г молоко
  • оливки
  • каперсы
  • 1 яйцо
  • соль
  • перец
  • чеснок Читать →

Как работает Auto-Tiering (ярусное хранение данных) в DataCore SANsymphony-V

Сегодня речь пойдет о механизме работы автоматического тиеринга в DataCore SANsymphony-V, программном продукте для виртуализации систем хранения данных. О том, что представляет из себя SANsymphony-V, решаемых задачах, функционале и нескольких референсных платформах можно почитать на сайте True System.
Ярусное хранение данных (tiering) — одна из самых обсуждаемых последнее время технологий. Вы наверняка слышали о том, что это некий способ автоматически перераспределять «горячие» и «холодные» данные между быстрыми/дорогими носителями и дешёвыми/ёмкими/медленными. Для начала стоит рассказать об основах (например, отличия от простого одноуровневого кэширования), затем можно будет перейти к конкретной реализации в DataCore SANsymphony-V. Принцип работы одноуровневого кэша достаточно прост. На примере реализаций в SAS RAID контроллерах (LSI CacheCade и Adaptec MaxCache) это выглядит так:

  • Создается пул из SSD, используемых для кэширования. При включённом кэшировании запись он, естественно, должен быть защищённым (RAID 1, 1E, 10, 5).
  • Тома на контроллере имеют простую настройку «кэшировать / не кэшировать».
  • При включённом кэшировании контроллер анализирует доступ к данным тома и копирует часто читаемые блоки в кэш. Если включён write-back, то любая запись попадает сначала в кэш, затем вытесняется на том.

Простой способ подходит для простой задачи — обеспечить гибкий прирост производительности. Самый распространенный сценарий: база достаточно большого для размещения полностью на SSD-томе объема, к определенным таблицам которой нужно обеспечить быстрый доступ. Но при наличии более сложной ситуации возникают проблема, связанные, во-первых с наличием только двух уровней производительности (исходный том + SSD-кэш), во-вторых — отсутствие какого-либо QoS. Что делать, если кэшируемых томов несколько и одному из них нужен приоритетный доступ к кэшу? Просто взять и поделить кэш (например — 50ГБ для первого тома, 100ГБ — для второго) нельзя, придётся вручную размещать нужные данные на SSD-томах, что противоречит исходной задаче по увеличению эффективности использования быстрых, но дорогих носителей.
Что делать, если жизненный цикл ваших данных сложнее, в наличии имеется несколько томов на разных СХД с различной производительностью, и есть необходимость организовать автоматическое «оседание» редко используемых данных на медленных носителях?
Тут на помощь приходит ярусное хранение данных и устроено оно несколько сложнее, чем просто многоуровневый кэш. Разберём принцип работы на примере DataCore SANsymphony-V (далее — SSV). С некоторыми отличиями тот же принцип используется и в других реализациях, например в IBM SVC.
SAU (storage allocation unit). Логические блоки, на которые нарезается дисковое пространство в пуле. В SSV размер SAU может быть от 4-х до 1024МиБ. В других системах могут называться chunks, logical blocks и т.п. Именно с дискретностью в один SAU осуществляются все операции — выделение дискового пространства для томов, операции по перемещению данных при использовании ярусного хранения и т.п.
Tier (ярус, уровень) — свойство, назначаемое диску в пуле (под термином диск подразумевается не одиночный диск, а некий используемый SSV защищённый том, например, с локального RAID-контроллера или внешней СХД). SSV ничего не знает о физическом устройстве диска (тип RAID, кол-во и тип физических дисков в нём) и, как следствие — о производительности. Так что tier’ы присваиваются вручную. Их можно создать до 15-ти, но в большинстве случаев достаточно трёх-четырёх. Важно, чтобы по производительности на случайный доступ они существенно (хотя бы в разы) отличались друг от друга. Операции по перераспределению данных между ярусами создают дополнительную нагрузку, так что желательно, чтобы они выполнялись не зря.
Кажется, что все необходимые для организации ярусного хранения компоненты уже есть. Но как быть с теми же приоритетами? Для решения этой задачи у тома (виртуального диска DataCore) есть storage profile (профиль хранения), который помимо приоритетов не относящихся к ярусному хранению (приоритет репликации и приоритет восстановления для зеркальных томов) определяет т.н. tier affinity, привязку тома к определенным ярусам. Например, для конфигурации с 4-мя ярусами и пятью профилями (critical, high, normal, low и archive) tier affinity выглядит так:

Том с профилем normal (обычный) привязан ко всем ярусам, т.е. его SAU в зависимости от частоты использования могут свободно мигрировать между любыми ярусами. Для обеспечения гарантированного уровня производительности тому можно назначить приоритет high (высокий) или даже critical (критичный). Например, для профиля critical SSV будет стараться разместить все данные тома исключительно на дисках первого, самого быстрого яруса, причём они будут иметь приоритет перед томами с более низкими профилями, привязанными к этому ярусу. Т.е. SAU на томе со storage profile = critical будут полностью размещаться на дисках tier-1, если при этом для остальных томов с high или normal на ярусе tier-1 не останется места, то их SAU будут перемещены на менее производительные ярусы.
Вы можете спросить, чем же ручное назначение профилей томам существенно отличается от использования простых СХД без всякого tier’инга, с ручным распределением данных по томам с нужной производительностью. Сценариев много:
отличается эффективностью использования дорогостоящего пространства на SSD — до тех пор, пока тома с наивысшим приоритетом не исчерпают всё быстрое пространство, вы можете поделиться им с другими томами;

  • даже если вы столкнулись с нехваткой быстрого пространства — не беда, не нужно ничего останавливать и перемещать, часть данных временно осядет на более медленных ярусах до тех пор, пока не появится свободное место за счет удаления данных или добавления дискового пространства;
  • отсутствие даунтайма при любых изменениях в приоритетах производительности, так все перемещения абсолютно прозрачны для приложения, SSV продолжает отдавать те же LUN’ы, просто меняя в фоновом режиме физическое расположение данных;

Как это выглядит на практике
Рассмотрим управление ярусным хранением на примере DataCore SANsymphony-V 9.0. Заодно будут разъяснены различные улучшения в новом релизе 10.0.

На виртуальном стенде с SSV у нас есть пять физических дисков в одном пуле. Мы можем представить, что это физические бэкенды трёх категорий производительности: массивы (с одинаковым типом RAID и примерно одинаковым количеством дисков) из SATA HDD, массивы из SAS HDD и массивы из SSD, и присвоить им различные ярусы.

Далее можно создать несколько виртуальных дисков (томов). По умолчанию всем присваивается профиль normal.

Обратите внимание: в версии 10 появилась возможность задать резервирование до 20% свободного места на каждом ярусе в пуле. Это помогает сократить количество операций по перемещению данных между ярусами. Новые SAU для тома, имеющего профиль с высоким приоритетом, будут выделяться из этого зарезервированного пространства. Отсутствие предварительного резервирования при условии заполненности быстрого яруса привело бы к тому, что SAU сначала были бы выделены на нижних ярусах, а потом в соответствии с профилем их нужно было бы переместить наверх, предварительно переместив вниз данные с менее приоритетных томов.

Вот так выглядит изначальное распределение данных по ярусам для тома vd03_test_mirror. Тёмно-синим подсвечены «горячие» данные. По умолчанию SSV для Auto-Tiering’а отслеживает только нагрузку на чтение. В SSV 10 появилась не только экспериментальная поддержка отслеживания нагрузки на запись, но и синхронизация т.н. heat map’ов (таблиц распределения «горячих» данных) между двумя узлами, на которых размещён зеркальный том. Это помогает избежать ситуации с резким снижением производительности при отказе основного узла.

 

Сменим профиль тома vd03_test_mirror на archive. Этому профилю соответствует tier affinity с привязкой только к самому медленному ярусу Tier-3. Данные (с гранулярностью на уровне отдельных SAU) начинают перемещаться вниз. Обратите внимание на то, что том всё ещё нагружен, все области подсвечены тёмно-синим, но политика размещения уже не даёт занять пространство на быстрых ярусах.
Для того, чтобы снизить влияние перемещения данных на производительность, SSV производит операции по миграции SAU в соответствии с несколькими т.н. планами миграции:
Высокоприоритетный план (перемещается один SAU в секунду):

  • перемещения, необходимые для соблюдения tier affinity. Например, место на нужном ярусе закончилось и приходится выделять новые SAU на медленных ярусах, но затем нужно привести всё в соответствии с tier affinity, чтобы обеспечить высокоприоритетным томам должный уровень производительности;
  • при плановом отключении диска. Допустим, мы планируем отключить для обслуживания (или вообще списать) целую СХД, тома с которой использует SSV. Естественно, это необходимо сделать как можно скорее;
  • при изменении назначенного яруса для физических дисков или изменении профиля для тома SSV (виртуального диска);

Обычный план (перемещается один SAU раз в 30 секунд):
все остальные перемещения основаны на мониторинге нагрузки, т.е. на статистике доступа к SAU («горячие»/»холодные» данные).

Все данные с vd03_test_mirror осели вниз, на медленный tier-3, освободив дорогостоящее быстрое дисковое пространство первого и второго ярусов.
Этот финальный скриншот уже из 10-й версии SSV, где разработчики дополнительно решили поменять визуализацию распределения SAU. Теперь акцент сделан на соотношении объемов горячих/холодных данных и свободного пространства, без учёта малополезной для администратора информации о точном расположения SAU на физических дисках.
Заключение
Как обычно, если вас интересует более подробная информация по любой теме, описанной в данном блоге, или нужен демо-стенд, то вы всегда можете обратиться в компанию True System.

Автор: Dmitry Nosachev