Find Communities by: Category | Product

Yanhong Huang

EMC 2014 Q2财报速读

Posted by Yanhong Huang Jul 23, 2014

昨晚,EMC公布了2014 Q2的财报。股票往上迅速突破29美元啊,最后收在了285左右。下面,我给大家分享下这次财报中的一些重要的看点。

 

  • Q2收入达59亿美元,比去年同期增长5%。在当前环境下,实属难得。
  • Q2公认会计准则每股收益0.28美元,非公认会计准则每股收益0.43美元。表现不错,由此全年每股收益目标提高了1美分。
  • 2014年计划回购股票的金额从原来的20亿上升为30亿
  • Q2收入方面,VMWare比去年同期增长17%Pivotal比去年同期增长29%。都达到了2位数。

 

具体产品方面,中端存储7%年增长率;新兴存储(XtremIO, Isilon, ViPR)年增长率52%DD这块也有两位数的增长;RSA增长6%VCE的增长也非常强劲。随着VMAX3的发布,高端存储下半年也要发力了。

 

从地区看,美国地区收入有3%年增长,占了总收入的52%。美国以外地区收入年增长达到7%,占了48%。其中,欧洲中东非洲年增长率12%,拉丁美洲14%,金砖四国和其他13个发展中市场增长5%

 

想要了解更多的细节,大家可以参考

http://www.emc.com/about/news/press/2014/20140723-earnings.htm?pid=hp-earnings-release-230714

对于IBM大型机,连接识别存储后(VMAX),用户往往需要对逻辑卷设定自己定义的卷标(EMC只提供默认的卷标,一般是SYMXXX标识,而且可以重复)。

IBM主机上执行相应的命令可以修改。比如:

INIT UNITADDRESS(xxxx) VOLID(yyyyyy) VTOC(0,1,60) INDEX(4,1,60) VERIFY(zzzzzz) PURGE

可是在现在连接的大型存储中,逻辑卷数目非常巨大,这个更改卷标的操作往往要耗费非常长时间(比如几千个逻辑卷,可长达一天甚至数天)。

建议在存储安装前,客户和EMC实施人员在谈设计规划时,就提供需要定义的卷标号,然后可以由EMC工程师在配置文件中直接设定,如下图(Symmwin图例),这样安装后,用户即可得到所需的卷标了。

ibm.png

注意有两个操作完成卷标更改。建议用下面一个“Set CKD Labels”,因为它专为CKD卷的规则设计,可以避免使用重复的卷。在开放系统中,重复的卷标识合法的,但CKD环境不允许。

如果VMAX新安装结束后,才要求EMC工程师来更改这些卷标,则 步骤变得很复杂。VMAX不允许在线更改卷标。虽然用删除-重新创建能完成更改,但还不如客户自己在主机上发命令去完成更改了。

有VMAX3,XtremIO,Isilon。一页PDF全部包含,大家可以先睹为快!

    数据迁移长久以来一直是一个困扰用户的问题。随着IT系统的复杂性与日俱增,制定迁移方案也经常是存储管理员非常头疼的一件事。要实现在线的迁移有时候的确也是不小的挑战。

    正是针对这样一个背景,EMCSymmetrix VMAX推出了Federated Live Migration这样一个全新的特性。

       Federated Live Migration提供从DMX/VMAXVMAX的真正无中断迁移。FLM将基于阵列的数据迁移(由 EMC Open Replicator for Symmetrix 提供)与主机级别的应用程序重定向(由 EMC PowerPathVeritas DMP或主机 MPIO 提供)联系在一起,从而实现上述功能。 它通过EMC图形化管理软件或SYMCLI 使用一组协调命令启动迁移会话,并从一个中心点协调主机应用程序重定向,确保迁移过程真正无中断。此外,Federated Live Migration 还支持大量预先审核过的阵列堆栈、PowerPath和主机操作系统,它们可帮助避免耗时的补救过程。Federated Live Migration也相当灵活;它能够支持密集到密集、密集到精简和精简到精简的迁移组合,并支持将多个系统整合到一个 Symmetrix

      Federated Live Migration (FLM) 允许用户将数据从旧存储移动到新的Enginuity 5875/5876 阵列,而不会造成应用程序主机停机。Federated Live Migration (FLM)的运行方式为:使新的 VMAX 设备采用原 Symmetrix DMX 设备的标识和结构,然后执行 Open Replicator (ORS)操作作为新阵列和原阵列之间的当前数据移动方法。新的VMAX设备必须等于或大于原DMX设备,才允许执行迁移操作。原存储必须为 Symmetrix,而原设备不能参与任何类型的本地或远程复制。需要进行此限制,才能确保新设备上的数据完整性,因为如果在运行Open Replicator 拉入会话时将新数据写入原 DMX 设备,则该会话将无法复制一致的数据。

 

FLM 配置包括网络、存储阵列、应用程序主机,以及 Solutions Enabler(SE) 主机,如下所示:

1.png


Federated Live Migration主要应用于以下的两个场景:

2.png


Federated Live MigrationMigration Flow如下:

3.png

  • 最开始的时候我们可以看到应用是跑在旧的DMX阵列上的
  • 紧接着,我们在VMAXFADMXFA之间建立一个可用的Zone,以保证他们之间能够通信
  • 主机的HBA和新的VMAX前端口之间也要建立好Zone

 

4.png

  • 在新的VAMX阵列上根据具体需要创建好一个新的device,并且map到此存储的前端口上。在第四步和第五步之间新的FLM session必须被创建,此时新的VMAX上的device会进入一种叫passive的状态
  • 在第五步,我们把新的VMAX devicemasking让主机看见
  • FLM session被激活后新的VMAX device会改变成active的状态,而原先的DMX上的device会变为passive状态。此时VMAX上运作的是ORS Hot Pull with Donor Updatesession。此时hostIO便被重定向到VMAX device上了



下面提供一个简单实际的操作案例供大家参考:

1. 创建一个文件,里面包含标准ORS Pull Sessionsourcetarget 设备

## FLM PAIR FILE

##

## COLUMN1: FLM Target [ VMAX - 5875 ]

## COLUMN2: FLM Source [ DMX - 5671 ]

symdev=000194900275:0328 symdev=000187490076:0720

symdev=000194900275:0329 symdev=000187490076:075F

symdev=000194900275:032A symdev=000187490076:07B6

symdev=000194900275:032B symdev=000187490076:07E9

 

2. 使用命令 symrcopy create –pull –migrate 创建一个NoCopyFLM session

C:\> symrcopy -f win_flm create -pull -migrate -host_type windows -mp_type ppath_45

 

3. 使用symrcopy query命令去验证FLM Pairs出现在Migration Session中,并且已经在Created State

C:\> symrcopy -f win_flm query

Device File Name : win_flm

       Control Device                  Remote Device      Flags      Status Done

---------------------------- --------------------------- ------- -------------- ----

Protected

SID:symdev Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

------------------ --------- ------------------------ -- ------- -------------- ----

000194900275:0328 60000 000187490076:0720        SD ...XXM. Created         N/A

 

Flag列下面的M代表着这是一个FLM Migration Session

 

4. VMAX上的DeviceMapMasking

C:\> symaccess –sid 275 create view -name win_flm_mv -sg win_flm_sg -pg win_flm_pg  -ig win_flm_ig

C:\> symaccess -sid 275 show view win_flm_mv

 

5. 主机端验证VMAXdevice已经可以被主机看见了

C:\> powermt display dev=all

Pseudo name=harddisk14

Symmetrix ID=000187490076

Logical device ID=0720

state=alive; policy=SymmOpt; priority=0; queued-IOs=0

==============================================================================

---------------- Host ---------------   - Stor - -- I/O Path -  -- Stats ---

### HW Path                 I/O Paths    Interf. Mode    State  Q-IOs Errors

==============================================================================

   5 port5\path0\tgt10\lun6    c5t10d6   FA 14cA active  alive      0 0

   5 port5\path0\tgt11\lun6    c5t11d6   FA 14cB active  alive      0 0

   5 port5\path0\tgt4\lun1     c5t4d1    FA 7eC   active  dead 0      1

   5 port5\path0\tgt6\lun1     c5t6d1    FA 8eC   active  dead 0      1

 

6. 激活FLM session

C:\> symrcopy -f win_flm activate -migrate

 

7. 确认FLM Session正在Copy数据

C:\> symrcopy -f win_flm query

Device File Name : win_flm

       Control Device                  Remote Device      Flags Status    Done

---------------------------- --------------------------- ------- -------------- ----

Protected

SID:symdev Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

------------------ --------- ------------------------ -- ------- -------------- ----

000194900275:0328 45580 000187490076:0720        SD X..XXM. CopyInProg       24

000194900275:0329 45399 000187490076:075F        SD X..XXM. CopyInProg       24

000194900275:032A 45411 000187490076:07B6        SD X..XXM. CopyInProg       24

000194900275:032B 550 000187490076:07E9        SD X..XXM. CopyInProg       96

Total ---------

  Track(s)            136940

  MB(s)               8558.8

 

8. 确认主机端应用已经从原先的DMX切换到VMAX上了

C:\> powermt display dev=all

Pseudo name=harddisk14

Symmetrix ID=000187490076

Logical device ID=0720

state=alive; policy=SymmOpt; priority=0; queued-IOs=0

==============================================================================

---------------- Host ---------------   - Stor - -- I/O Path -  -- Stats ---

### HW Path                 I/O Paths    Interf. Mode    State  Q-IOs Errors

==============================================================================

   5 port5\path0\tgt10\lun6    c5t10d6   FA 14cA active  dead       0 1

   5 port5\path0\tgt11\lun6    c5t11d6   FA 14cB active  dead       0 1

   5 port5\path0\tgt4\lun1     c5t4d1    FA 7eC   active  alive 0      1

   5 port5\path0\tgt6\lun1     c5t6d1    FA 8eC   active  alive 0      1

 

9.过了一段时间后,确认FLM拷贝已经完全结束了

C:\> symrcopy -f win_flm query

Device File Name      : win_flm

Control Device Remote Device      Flags      Status Done

---------------------------- --------------------------- ------- -------------- ----

                   Protected

SID:symdev         Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

------------------ --------- ------------------------ -- ------- -------------- ----

000194900275:0328          0 000187490076:0720        SD X..XXM. Copied          100

000194900275:0329          0 000187490076:075F        SD X..XXM. Copied          100

000194900275:032A          0 000187490076:07B6        SD X..XXM. Copied          100

000194900275:032B          0 000187490076:07E9        SD X..XXM. Copied          100

Total              ---------

Track(s)                 0

MB(s)                  0.0

...

C:\> symrcopy -f win_flm verify

All device(s) in the list are in 'Copied' state.

 

10. Terminate结束了的FLM Session

C:\> symrcopy -f win_flm terminate -migrate

     大家都知道对于NASCIFS 来说,NTLMKerberos是两个比较重要的验证方式。今天我们来讨论一下作为CIFS安全认证之一的Kerberos协议。

         Kerberos 是一种依赖于验证技术共享密钥的协议,其基本概念很简单,如果一个秘密只有两个人知道,任何一个人都可以通过他们之间共享的秘密来确定对方的身份。用技术的语言来讲,就是对称加密,互相确认。

     说到这里,可能有人会问,NTLM也是CIFS的安全认证啊,为什么Kerberos会用的更广泛呢?他的优点又在哪呢?相信大家了解了Kerberos的工作原理之后就会清楚了。

 

Kerberos认证和我们看电影的过程差不多,主要分三个步骤:

第一步咨询:用户登陆domain

第二步买票:用户获得service票据

第三步来访:使用服务票据访问某服务

kerberos.png

 

 

  • 用户登陆domain (Logging into the Domain)

1. Authentication Server request

    AS_REQ,即上图步骤(1)

 

           一个用户在一台Client机上第一次登陆时,会有弾框提示输入用户名和密码。这时用户密码信息会通过Hash算法产生一个用户的Long Term Key(LTK),再和用户登陆Client端时的时间戳一起进行加密,然后这个用户验证请求被发送给Kerberos Data Center(KDC),并要求KDC返回一个相应的Ticket Granting
Ticket(TGT)

 

2. Authentication Server response

     AS_REP,即上图步骤(2)

 

 

        KDC在数据库中先找到该用户的密码,并用同样的Hash算法生成一个LTK 然后KDC通过LTK从预认证信息PreauthKRB_AR_REQ中解密出用户信息和时间戳, 如果用户信息无误,并且时间戳和目前信息相差在5分钟之内,KDC会认为该用户验证通过。KDC将生成一个TGT,并准备把TGT返回给Client

 

 

     在生成TGT的同时,KDC生成一组随机数作为Logon Session Key,并让他和客户端传来的LTK再次进行加密,产生一个名叫enc-part的信息放在该KRB_AS_REP包中,KDC还会用生成的TGT与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGT的头中,这样就得到了一个只有KDC能解开的TGT,最后把这个TGT加入KRB_AS_REP包中并发送至Client端。

 

3. Ticket cache

           Client端收到KRB_AS_REP后会用自己的LTK来解密KRB_AS_REP中的enc-part,这里我们默认会得到KDC选用的随机数Logon Session Key。这时候Client端将会把得到的Logon Session KeyKRB_AS_REP中带有原始时间戳的TGT一起存入票据内存中准备给下面过程使用。

PS:这时候KDC为了减少自身负担,并没有吧Logon Session Key保存在自己这边,所有只有这个用户在Client端的票据内存里面才有该记录了。

 

 

  • 用户获得service票据(Getting a Service Ticket)

 

1. Ticket Granting Server request

     TGS_REQ,即上图步骤(3)

 

 

Client端接下来会拿着TGT去告诉KDC我要访问某服务,并让KDC给他访问该服务的票据(service ticket),以后他就可以拿着这张票据直接访问该服务了. Client端用现在的时间戳和之前存在票据内存中的Logon Session Key进行加密生成Authenticator,然后再把带有原始时间戳的TGT一起打包发送给KDC等待验证。

 

2.  Ticket Granting Server response

     TGS_REP,即上图步骤(4)

 

KDC收到KRB_TGS_REQ后会用自己的LTK解密出TGT,然后看看TGT中的原始时间戳,如果来确定TGT现在还是处于有效的状态,KDC就会从TGT中读取Logon Session Key,并用这个Logon Session Key解密Authenticator来获得第二次记录的时间戳,如果该时间差在5分钟之内,KDC认为验证成功,并将生成一个service ticket

PSKerberos为了防止重演攻击,特别加入了对时间戳的验证。

接下来KDC又会生成一组叫做Service Session Key的随机数,并把这组随机数和service ticket中记录的Logon Session Key进行加密,产生一个名叫enc-part的信息放在该KRB_TGS_REP包中,KDC还会用生成的service ticket与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGS的头中,这样就得到了一个只有KDC能解开的service ticket,最后把这个service ticket加入KRB_AS_REP包中并发送至Client端。

 

3. Ticket Cache

 

     Client收到KRB_TGS_REP后,通过票据内存中的Logon Session Key解密enc-part,然后得到KDC生成的Service Session Key。最后把Service Session Keyservice ticket一起作为访问目标服务器的Credential存入票据内存中。

 

 

  • 使用服务票据访问某服务(Using the Service Ticket)

 

1. Application Server request

    AP_REQ,即上图步骤(5)

   

     经过上面的两次验证,Client现在就能拿着服务票据去访问该服务了。Client记录下时间戳,并读取内存中的Service Session Key与他进行加密生成新的Authenticator,同时用户还要标记好自己是否需要双向认证 (Mutual
Authentication)
,最后再加上之前的服务票据一起发送给该服务的server(NAS系统中相对应的服务就是CIFSserver就是我们加入domainCIFS server)

 

2. Application Server response

     AP_REP,即上图步骤(6)

 

NAS收到这个加密的KBR_AP_REQ之后,用自己的LTK进行解密。接着serverservice ticket里面读出service session Key来解密Authenticator中的时间戳。如果时间差小于5分钟,NAS就允许该用户对他进行访问了,并且为这个Client上的这个用户创建一个security token

 

Kerberos优点:

 

虽然上面Kerberos的工作原理稍微有点复杂,不过我们还是能从中看出Kerberos的高效性,相互身份验证以及互操作性的优点。

 

  1. 高效性:客户端不用每次访问NAS时都去DC验证,而通过查询client credentials就可以验证了。
  2. 相互身份验证:clientserver可以互相验证。
  3. 互操作性:微软的Kerberos V5实现是基于IETF的推荐标准规范。这样,Windows Server 2003Kerberos V5实现就为其他使用Kerberos V5协议的网络的互操作打下了基。

Filter Blog

By date:
By tag: