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

Опубликованы результаты Q3FY2017

Опубликованы результаты Nutanix для Q3FY2017, то есть третьего квартала финансового года 2017 (у нас, как это принято в Америке, финансовый год начинается в сентябре).

Скучные подробности про GAAP ищите на соответствующих сайтах, а пока — традиционная уже картинка:

Наш новый партнер — IBM!

Как вы знаете, существенная часть продаж Nutanix — это наши продажи через OEM-партнеров. Поэтому ничего удивительного в том, что мы продолжаем активно развивать наш OEM-бизнес на рынке. До сегодняшнего дня у нас было, официально, два OEM. Это Dell, и его модельная линейка гиперконвергентных систем Dell XC (фактически — сервера PowerEdge и Nutanix как софт на них, продаваемые через канал Dell), и Lenovo (как Lenovo HX, на тех же условиях). Да, у нас есть эксперименты с установкой Nutanix на платформы Cisco UCS C и UCS B, и даже, с недавних пор, на HP ProLiant DL (мы пока не предлагаем это в России, но они есть), но это не OEM, официальных «настоящих» OEM у нас было два.

И вот к этим двум добавился еще один — IBM! Особое соглашение, под названием multi-year agreement было заключено между Nutanix и IBM.

ibm logo

«Погодите,» — скажете вы, «Но ведь у IBM больше нет серверов x86, они все теперь у Lenovo! У IBM остались только системы серверной архитектуры Power8, так это что ж значит?..»

Да! Nutanix AHV портирован на Power, и IBM будет поставлять Nutanix AHV на своих 1U- и 2U-серверах платформы Power как готовый appliance!

power8 logo

Основная цель для подобных систем — Linux-приложения на платформе Power, опернсорсные базы данных Cassandra и MongoDB, приложения на Java в WebSphere, BigData и AI (Artificial Intelligence).

Официальный анонс соглашения — сегодня, анонс первых продуктов, спецификации и цены — 28 июня, на .NEXT, нашей главной партнерской технологической конференции.

Чтобы соблюсти юридические формальности: Партнерство IBM и Nutanix официально не называется «OEM» (но, фактически является схожим с ним по сути), IBM будет поставлять свое оборудование, под своим именем, но с нашим софтом внутри. Фактически условия эти аналогичные OEM, например с Dell. Но при этом мы договорились, что это не будет называться так. Это, официально, зовется multi-year agreement. Давайте его так и будем называть.

Официальный пресс-релиз — тут: https://www.nutanix.com/press-releases/2017/05/16/ibm-nutanix-launch-hyperconverged-initiative-bring-enterprises-cognitive-era/

Пароль для admin в новом Nutanix OS 5.1

Я чуть ранее упоминал о нововведении в свежей версии Nutanix OS. Из соображений безопасности мы теперь будем требовать обязательного изменения/установки пароля админа на служебные сервисы Nutanix. Конечно, по-хорошему, доступ к CVM должен быть ограничен VLAN-ом админов, но пользователь ленив, и если есть возможность что-то усложняющее жизнь не делать — он и не сделает. Поэтому теперь рутовый-админский доступ будет закрыт паролем, который пользователь должен будет устанвить сам при запуске системы.
Мы несколько ранее сделали такое для доступа в Prism, но теперь это будет и для CVM тоже. Выглядит это так:

Прежде чем вводить пароль и тыкать кнопку, прочтите и осознайте внимательно примечание, написанное под полем пароля.

Конечно, мне тоже кажется, что со строгостью password policy у нас все же несколько перестарались, сгоряча :)
Тем не менее, теперь будет вот так.
Обратите внимание, что первые пользователи уже столкнулись с несколькими тонкими моментами.
В качестве спецсимволов новые политики не принимают, например, популярные в качестве special characters: ! @ $ /. Дефис подходит.

Пароль админа после введения на одном из нодов, синхронизируется по всему кластеру.

Как задействовать на ноде Nutanix под трафик VM более одного порта 10G?

Стандартная конфигурация сети ноды Nutanix — это два порта 10G в конфигурации active-passive, при котором один работает и передает данные как межкластерного соединения, так и обеспечивает внешнюю сеть для VM, а второй стоит на случай отказа первого или его коммутатора. И поэтому у многих сисадминов чешутся руки и второй также задействовать для передачи данных, сделав на них какой-нибудь «LACP».
Это возможно. Но прежде чем мы пустимся дальше — несколько слов напутствия. Вариант с active-passive выбран нами как вариант по умолчанию не зря. Наш опыт конфигуирования систем Nutanix показывает, что для подавляющего большинства систем один хост не исчерпывает своим трафиком возможности одного порта 10G, поэтому расширение полосы пропускания в неиспользуемой части ее не увеличит быстродействие вашей системы. К тому же любой сетевик скажет вам, что active-passive это наименее проблемная конфигурация с точки зрения глюков, и самая простая в настройке. А раз так — то зачем нам приключения?
Но если так оказалось, что вы в самом деле уперлись на вашей системе Nutanix в трафик порта (такое может случиться с высоконагруженными системами производительного семейства NX-8000, например), то одним из вариантов будет задействовать два (или даже больше) порта для одновременной передачи данных по ним.
И вот как это возможно.

Первый, приходящий в голову способ будет у вас, я думаю, задействовать LACP. Это возможно, и прежде всего для этого надо переключить значение bond_mode на OpenvSwitch в Acropolis для OVS-бонда с active-passive на balance-tcp.
Однако это, хотя и позволит нам задействовать LACP, не решит проблему с одной высоконагруженной VM. Дело в том, что такая VM, обладая всего одним source IP, не сможет в случае балансировки LACP задействовать более одного порта, так как балансировка в этом режиме идет по парам source-target IP. Начав передавать трафик по одному интерфейсу, она и будет продолжать по нему передавать, даже в случае, если объем трафика превысит его полосу пропускания. Другая VM, с другим source IP пакета, конечно, сможет использовать для своего трафика второй eth, но только таким образом.

Чтобы избежать такой ситуации, мы попробуем другой режим балансировки, в OVS он называется balance-slb.
Вот как его включить.

Допустим, у нас конфигурация сетевого бонда на ноде вот такого типа:

Здесь, как вы видите, оба порта 10G объединены в сетевой бонд с именем bond0 и включены в бридж по имени br0.

Команда:
hostssh ovs-appctl bond/show bond0
покажет нам конфигурацию OVS на всех хостах кластера. Выглядит это примерно так:

Как вы видите, значение bond-mode у нас всюду active-backup.

Дадим команду:
hostssh ovs-vsctl set port bond0 bond_mode=balance-slb

и она переключит нам режимы бондов с именем bond0 для ВСЕХ хостов на balance-slb

[Если вам необходимо сделать это только для одного конкретного хоста, то тогда из консоли CVM этого хоста дайте команду:

ssh root@192.168.5.1 ovs-vsctl set port bond0 bond_mode=balance-slb]

В результате вы получите такое:

Теперь действующий режим бонда стал balance-slb.

Обратите внимание на обведенное зеленой рамкой. Это указывает время перебалансировки портов. Значение по умолчанию для перебалансировки — 10 секунд, но Nutanix рекомендует устанавливать значение перебалансировки на 60 секунд, чтобы минимизировать «скачки» VM и ее трафика с порта на порт.

Команда:
hostssh ovs-vsctl set port bond0 other_config:bond-rebalance-interval=60000
установит это значение.

Данный метод работает для AHV 20160925.43 и AOS 5.0.2

Больше про балансировку и особенности работы сети в AHV — в статье: https://next.nutanix.com/t5/Nutanix-Connect-Blog/Network-Load-Balancing-with-Acropolis-Hypervisor/ba-p/6463

Nutanix OS 5.1 в релизе!

Главная новость недели это, конечно, выход в релиз новой свежей версии Nutanix OS — 5.1.

Nutanix Acropolis OS 5.1

Вот что нового в свежем релизе:

Наконец появилась возможность смешивать All-Flash ноды с Hybrid (SSD+HDD) в одном кластере. Раньше AllFlash можно было делать только в выделенном кластере. Теперь, начиная с двух нодов All Flash, их можно включать в Hybrid-node Cluster.

В AHV появился hot-plug для изменения объема памяти и числа CPU в виртуальной машине.

Для кластеров с лицензиями Pro и Ultimate для создаваемых контейнеров пост-процессная компрессия в них будет включена по умолчанию. Раньше это было только для All-Flash систем, теперь и для гибридных тоже. Starter исключен просто потому, что в нем нет post-process compression в наборе фич.

Поддерживается vSphere 6.5.

Улучшена работа Erasure Coding (EC-X).

Поддерживается гипервизор XenServer 7 для моделей NX-1065-G5, NX-3060-G5, NX-3175-G5. Основная цель поддержки этого гипервизора — работа VDI с 3D GPU NVIDIA Tesla M60
Не поддерживается XenServer на NX-6035C-G5.

Увеличился объем рекомендованного по умолчанию объема памяти CVM до 32GB (для систем с 64GB RAM — 28GB), при этом — хорошая новость: появился 1-Click memory size changer.

AHV сертифициован в Windows 2016 SVVP (Server Virtualization Validation Program).

В качестве Tech Preview(обычно это означает General Available статус в следующей версии):

GPU passthrough в AHV. Это пока не vGPU. Для полной поддержки GPU пока смотрите на XenServer+XenDesktop.

Поддерживается репликация, как синхронная, так и асинхронная между кластерами Nutanix и OEM (Lenovo HX и Dell XC). По-прежнему не поддерживается смешивание в одном кластере нативного Nutanix и OEM-систем.

Также обратите внимание, что теперь система будет требовать изменить при первом логине в CVM пароль админа. Если вы для ваших скриптов зачем-то использовали логин admin в CVM с нашим ранее дефолтным паролем, то это работать не будет. Измененный на одной из нод пароль для логина admin будет синхронизирован на всех нодах кластера. Мы рекомендуем создать для скриптов отдельный логин. Для пользователя admin (с root-правами) больше не будет доступен nCLI (Nutanix CLI, наш командлайновый интерфейс управления), только для «нерутового» пользователя.

Официальный Release Notes тут: https://portal.nutanix.com/#/page/docs/details?targetId=Release-Notes-Acr-v51:Release-Notes-Acr-v51

Как дела у Nutanix?

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

В последние несколько лет российский интернет расцвел многочисленными специалистами-экспертами на самые разнообразные темы, в народе их уже прозвали «диванными аналитиками». Какую бы тему не затронуть, уверен, вскоре в топик придут люди, детально разбирающиеся, или, по крайней мере, очень активно высказывающие свое мнение по затронутой теме. Диапазон широчайший, от похудения до тактико-технических характеристик зенитно-ракетных комплексов всех стран мира.
И уж конечно же всегда хватает аналитиков в области управления финансами. Особенно чужими. В русском народе издавна это называется «считать чужие деньги». ;)
Не избег этого и Nutanix.
Вот уже добрых полгода в любом нашем посте по поводу продукта обязательно найдется «специалист в финансовых рынках», сулящий нам скорое разорение, крах, нищету под забором и смерть от алкоголизма в колодце на теплотрассе, основываясь на графике стоимости акций. ;)

Но так ли все ужасно, и скоро ли Хьюлет Паккард (вариант: Хуавей) купит Нутаникс на сдачу от продажи десятка Супердомов?

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

Вот, например, как выглядел биржевой график цены акций за всю ее историю у хорошо знакомой всем и, безусловно, успешной компании:

Здесь легко видеть, что, после короткого и бурного роста сразу после размещения, курс начал падать и падал больше года, до начала 2009. После чего линейно попер вверх в течение двух лет, хотя даже в этом случае он так и не достиг цены акций, полученной в первые недели после размещения. Потом курс рос, снижался, опять рос, опять снижался, и несмотря на это компания VMware — это компания VMware.

Плохо это или хорошо? Да ни плохо, ни хорошо. Такова фондовая биржа, не зря к ней применяют слово «игра». Она давно уже живет не в понятиях, допустим, XIX века, когда если курс акций высокий — хорошо, курс снизился — плохо. Там давно уже все не так просто. Там свои механизмы, которые нам не видны, если вы только не профессиональный биржевой брокер, не зря сейчас на бирже допущены «играть» только они.

Еще пример? Пожалуйста.
Вот так выглядел первый год у еще одной большой и успешной сегодня компании. Как вы видите, в первые полгода курс акций упал более чем вдвое. В третьем и четвертом квартале чуть приподнялся, но все равно, что бы сказали, глядя на этот график уже знакомые вам «финансовые аналитики»? Ну, стали бы рассказывать, что дела плохи, что у компании скоро «кончатся деньги» и их «скоро купит кто-нибудь».

Давайте посмотрим, что произошло дальше, после первого года?

Парадоксально, возможно, но быстрый рост — не всегда хорошо (хотя слукавлю, если скажу что мне, как сотруднику компании, и владельцу shares, как это сегодня принято во многих американских компаниях, не хотелось бы, чтобы акции стоили побольше). Но и резкое падение — совсем не всегда означает обязательный крах, неудачу, скорое разорение и закрытие. Вот вам еще один характерный пример:

Во время «пузыря доткомов» стоимость акций компании, после практически экспоненциального роста, обвалилась в разы. И что, убило это компанию? Перестала она быть Cisco? «Погибла безвозвратно», разорилась и пошла с рыданием распродавать письменные столы и дыроколы из офиса? Нет, не пошла, и осталась Cisco, даже несмотря на то, что никогда с тех пор такой капитализации больше не имела, и прекрасно себя чувствует сегодня.

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

У Twitter в долгосрочной перспективе курс вообще никогда не рос, и практически линейно снижался прямо с самого момента размещения акций на бирже. И вы не живете в Америке, если скажете, что сегодня Twitter — не влиятельная и не успешная компания в глобальном масштабе. И такие примеры существуют еще.

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

Так что, накануне отчета за наш третий квартал, заканчивающийся вот-вот, давайте наберемся терпения, и сперва посмотрим, как закончится наш первый год в статусе публичной компании. И, нет, «не дождетесь» (с). ;)

Nutanix Acropolis Hypervisor best practices — на русском

Мы закончили перевод одного из наших документов серии Best Practices:
Nutanix Acropolis Hypervisor Best Practices (BP-2029) по самой свежей версии AHV, v5.0
Извольте знакомиться и пользоваться в работе.

Nutanix AHV Best Practices BP-2029 v.3 RUS

Nutanix Acropolis AHV BP v3.0 RUS

OCS и ОЛЛИ внедрили решение на Nutanix в автодилере Inchcape

Пресс-релизов вам в ленту. :) На этот раз новость от нашего дистрибутора — OCS, и его партнера «ОЛЛИ Информационные технологии», которые завершили сделку с крупным международным автодилером в России — Inchcape.

http://www.ocs.ru/PressCenter/PressReleases/2709/

«Компания Inchcape, дилер автомобилей BMW, MINI, Rolls-Royce, Volvo, Land Rover, Jaguar,Toyota, Lexus и Audi, переводит свою ИТ-инфраструктуру на гиперконвергентную платформу Nutanix.

Inchcape

В Inchcape длительное время использовалась классическая ИТ-инфраструктура, состоящая из серверов, СХД и сети SAN. Со временем она устарела и перестала устраивать по своей производительности и функционалу. В компании стали готовиться к замене оборудования и внимательно изучили современные альтернативы. Покупка новой СХД и серверов не совсем устраивала руководство ИТ, т.к. это означало высокие финансовые и ресурсные затраты. Требовалось разработать архитектуру решения, заменить все оборудование, обновить  SAN, выполнить миграцию, переобучить персонал и т.д. Для более долгого использования оборудование, пришлось бы выбрать более дорогие модели с запасом по производительности.

Специалисты компании «ОЛЛИ Информационные технологии», ведущего системного интегратора Северо-Запада, в результате консультаций с представителями Inchcape порекомендовали рассмотреть альтернативные варианты и обратить особенное внимание на гиперконвергентные решения. В результате, компанией Inchcape были тщательно изучены несколько конкурирующих систем. Одна из них не проходила по функционалу, другая – по стоимости. Наиболее подходящей была признана система Nutanix, модель NX-1465-G5. Эта модель, состоящая из четырех узлов, образующих единый кластер, включает в себя одновременно серверы, СХД и SAN, и занимает всего 2U в стойке. Поставки оборудования осуществила компания OCS Distribution.

Представители Inchcape отмечают: «Мы теперь можем не думать об устаревании оборудования и ограничениях по росту. Поскольку это программно-определяемое решение, то даже через несколько лет мы сможем получать новый функционал простым обновлением ПО. А сам кластер с нынешних четырех узлов можно масштабировать практически бесконечно. И через 5 лет нам не придется думать о переезде со старой СХД на новую. Мы просто будем добавлять новые узлы по мере необходимости, а физически изношенные выводить из эксплуатации без остановки сервисов. Нам также очень понравилась простота развертывания кластера Nutanix. Очень важный момент, что с момента распаковки оборудования до запуска приложений прошло всего три часа. Это фантастический результат! Виртуальные машины быстро мигрировали на новую инфраструктуру при помощи vMotion. Приложения работают быстро, в два раза сократилось время бэкапа, значительно упали задержки на дисковой подсистеме».

Высокая производительность системы достигается за счет того, что данные хранятся и обрабатываются на одном сервере. Кроме того, каждый узел Nutanix содержит как минимум один SSD, на котором хранятся «горячие» данные. Благодаря этому даже гибридная система работает практически так же быстро, как All-Flash сервер. А для экономии места на дисках возможно включение компрессии и дедупликации данных.

В настоящий момент Inchcape перевел на гиперконвергентную инфраструктуру терминальные сервисы, телефонию и почту. В планах компании на эту платформу и все бизнес приложения – 1С, SAP, базы данных и т.д. Встроенная репликация (как синхронная, так и асинхронная), позволит надежно защитить все критичные данные компании.»

Сколько в мире сегодня «гиперконвергентных решений»?

Наш коллега в своем блоге делает подсчеты и собирает индекс «гиперконвергентных решений», существующих на сегодня. У него получилось 34 (Тридцать Четыре!) продукта, без учета выбывших и «слившихся» с другими.
Конечно, добрая половина там — компании «ниже горизонта», не уверен даже что у них вообще есть хоть какие-то продажи, но сам факт!
В этом списке огромный диапазон компаний, от HP и EMC, до, например, QNAP и Promise. Поистине, сегодня гиперконвергенция — самая горячая тема в IT.

http://bythebell.com/2016/01/hyperconverged-players-index.html

Чем отличается SAN СХД от Nutanix?

После публикации о том, что в самой старшей модели, NX-8150, официально появилась поддержка 40GbE, стали часто задавать вопрос: «А почему нельзя заказать 40GbE и для остальных нод?» И для ответа надо немного более подробно рассказать о том, как именно работает устройство распределенного кластера Nutanix с точки зрения хранения данных, и почему нам не настолько важны «толстые» интерфейсы, особенно на не супермощных нодах-серверах.

Представим себе условную инфраструктуру, состоящую из 6 серверов, и SAN СХД. Допустим, для простоты иллюстрации, что на каждом из шести серверов работает прикладная задача, генерирующая около 2000 IOPS дискового трафика. Все эти серверы включены в SAN, и туда же включена и СХД.

Как мы видим на рисунке выше, это будет означать, что для обеспечения этих 2000 IOPS на каждом сервере, наша СХД будет должна обслужить и выдать 12 тысяч IOPS дискового трафика (без учета RAID penalty!). И чем больше будет становиться подключенных серверов, тем выше будет на нее нагрузка. Для такой СХД разумеется потребуется достаточно «толстый» интерфейс, иначе однажды серверы не смогут «протолкнуть» с СХД необходимый им трафик. В конечном счете производительность серверов будет определяться производительностью интерфейса к СХД и производительностью самой СХД, нагрузка на которую будет расти линейно увеличанию серверов или с ростом дискового трафика задач.

Другая ситуация в случае распределенного кластера хранения на Nutanix.
Представим такую же точно ситуацию, 6 серверов-нод, на каждом по 2000 IOPS. В отличие от «классической» SAN-инфраструктуры, у Nutanix нет единой консолидированной СХД, пространство хранения локально для каждой задачи, плюс каждая нода кластера хранит какую-то часть избыточных блоков. Избыточные блоки пересылаются на другие ноды с помощью канала 10GbE. Но этот канал не используется для доступа к дисковым данным у этого нода-сервера!

Каждый локальный диск отдает свои 2000 IOPS, что для современных SSD, совсем немного, и, при необходимости, может отдать и больше. Причем при увеличении инфраструктуры и добавлении еще серверов-нод, перегрузки какого-то отдельного компонента трафиком не возникает.
Вот здесь и кроется основная особенность распределенного хранилища Nutanix, вот почему нам не нужны на любой ноде сверхтолстые интерфейсы. Мы просто не гоняем по ним (весь) трафик. Да, бывают ситуации, когда толстый интерфейс нужен. Но это означает, не только то, что нода сама по себе высокопроизводительная, но и что задача на ней способна такой канал загрузить (прежде всего извне).

Давайте рассмотрим два крайних случая использования распределенного хранилища на шести нодах, по 2000 IOPS каждая: 100% чтение и 100% запись.
При 100% чтении все блоки данных будут читаться с локального хранилища, и межнодового трафика не будет практически совсем. Каждая нода дает 2000 IOPS и все.
Теперь наихудший с точки зрения межнодового трафика случай, 100% запись. При этом, как вы помните, каждый блок пишется локально, плюс, для избыточности, каждый этот блок записывается рандомно в одной или двух копиях, на одну или две ноды.

При этом вариант каждая нода пишет 2000 IOPS своего трафика, плюс 1/5 или 2/5 (в зависимости от RF=2 или RF=3) от этого трафика операций записи «чужих» блоков с пяти оставшихся нодов. В нашем случае это 2000+400 или +800 IOPS. То есть даже в наихудшем случае 100% рандомной записи, дисковый трафик на каждой ноде кластера не превысит 2400 или 2800 IOPS. Причем, отметьте, при увеличении числа нодов, эта «прибавка» будет падать, так как она будет размазана на все большее число нодов равномерно.
В реальной жизни, где объем трафика записи обычно ниже объема трафика чтения, значение прибавки в «1/5» в данном случае будет даже меньше.

Как совершенно справедливо заметил в комментариях один из читателей, написанный выше расчет относится к варианту, когда из 6 нод только одна делает 100% write, а остальные — read. В случае же, когда ВСЕ ноды делают 100% write (для простоты расчета возьмем, что все ноды делают равное число операций ввода-вывода), то наихудший случай даст нам на ноде 2x local IOPS. 2000 своих, плюс пять оставшихся нод пришлют нам на запись по одной пятой своих копий блоков, итого 4000 IOPS для RF=2 и 6000 для RF=3.

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

Практический пример?
Воспользуемся нашей демо-системой на demo.nutanix.com
Вот как выглядит ее загрузка на дашборде:

Как видите, 70 тысяч дисковых IOPS-ов на 4 нодах и 22 VM
Посмотрим, что делается при этом на сетевых портах нод и коммутаторе. Воспользуемся нашей новой фичей, Network Visualization:
Вот выше пример на одной ноде (на остальных трех ситуация аналогичная, трафикогенерирующие VM разбросаны по ним равномерно). Три-шесть мегаБАЙТА в секунду даже в пике!

А вот — статистика с порта коммутатора, соединяющего ноды вместе в кластер. Тоже семечки для 10GbE коммутатора, меньше миллиона пакетов в пике на порт.

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

UPD: Поправки, на которые обратил мое внимание в комментариях к посту коллега Nickolay.