Big Big Clusters / Data Centers

Hi folks. I have a bit of a theoretical question for the group, seeing as some of you should know how to handle this.
I am facing a job that could get quite big due to the sheer size of the nature of what it does. I would like to use Apple technology and MySQL. Naturally this comes down to XServes and XServe RAID.
I know MySQL has a table size limit of 2 TB. If I can juggle multiple raids and XServes, how does one go about designing something like this?
I will have a middleware taking incoming data (web services) as well as serving reports. So archives of data would need to be stored in MySQL. Nothing fancy. Pretty dry, relatively speaking.
So do I just create a whole bucket of xserves, put fibre channel between them, hook them up to these RAIDS, stripe them, and measure if I need to add more?
How does one go about designing one conceptually? What if my growth rates are doubling once a month? What limitations should I look for, assuming cash isn't a problem?
I didn't find much online, as I'm sure this is a rare application. I'm kind of blind with this, outside of my past experience.
Cheers

Hi there.
Please understand, that I have done some homework. I've looked at VT as well as the information on Apple's site. VT's storage seems rather light compared to what a data-intensive application might need, as opposed to a processing-intensive application.
As far as I can see, there is a 2 channel fibrechannel limit to an XServe RAID. Putting a loop together means that an increasing amount of data needs to be accessed through the LAN widths, so that places restrictions as well.
In the meantime, I've found a caching system that seems to alleviate the issue of massive amounts of data. It's a caching system called memcache.
I've done some calculations on the data I'll be dealing with, and similar large computers have the luxury of having time on their side with respect to serving and crunching. As you said hospitals, it is relatively small compared to my application.
As well, finding people to ask isn't a challenge. The reason I am posting here is to get insight on the direct application, not a suggestion to 'ask someone'. I am hoping within these forums, there is a way to start discussions on the topics themselves. I do have VT on the list of people to contact, but from the information they have online, it seems it could lead me towards something they might not know about. So, that's why I posted here, to see if anybody within these forums, would know the difference in the various cluster types that can be designed, and how to optimize them. It's not that VT isn't a solution, I just see it misleading and could be a very costly consulting job. Regardless, I do want to optimize forum questions in order to see what information I can get my head around before I just avoid getting non-stakeholder input by paying people to tell me about their solutions.
I also find that Apple cluster solutions are not that common. The largest data center here in Canada, doesn't have a single XServe in it, from what they tell me. It is the first reason I am asking in these forums.
I do have an MBA and know how to contact people to ask questions. It won't discard me asking here.
Cheers

Similar Messages

  • How can I return a big amount of data from a stored procedure?

    How can I return a big amount of data from a stored procedure in a efficient way ?
    For example not using a cursor for going through all the rows and then assign the values to variables.
    thanks in advance!

    Let's see if I'm able to explain myself..
    I have a SQL query with..about 190.000 (in the best fo the the options)
    I have something like this in my stored procedure..
    FOR REC IN trn_adj_no
    LOOP
    REC_PIPE.INSTANCE_ID:=REC.INSTANCE_ID;
    REC_PIPE.PROCESS_ID:=REC.PROCESS_ID;
    REC_PIPE.ENTITY_TYPE:='TRANSACTION';
    REC_PIPE.CRES_FILENAME:=REC.CRES_FILENAME;
    REC_PIPE.CHUNK_REVISION_SK:=P_CHUNK_REVISION_SK;
    REC_PIPE.CHUNK_ID:=trim(p_chunk_id);
    REC_PIPE.FCL_SK:=REC.FCL_SK;
    REC_PIPE.FCL_TRADE_SK:=REC.FCL_TRADE_SK;
    REC_PIPE.FCL_VALUATION_SK:=REC.FCL_VALUATION_SK;
    REC_PIPE.FCL_BUSINESS_GROUP:=REC.FCL_BUSINESS_GROUP;
    REC_PIPE.ABS_TRN_CD:=REC.ABS_TRN_CD;
    REC_PIPE.ACC_INTEREST_IMP_LOAN_CCY_IFRS:=REC.ACC_INTEREST_IMP_LOAN_CCY_IFRS;
    REC_PIPE.ACC_INTEREST_IMP_LOAN_IFRS:=REC.ACC_INTEREST_IMP_LOAN_IFRS;
    REC_PIPE.ACCRUED_INT_AMT:=REC.ACCRUED_INT_AMT;
    REC_PIPE.ACCRUED_INT_CCY_CD:=REC.ACCRUED_INT_CCY_CD;
    REC_PIPE.AMORT_ID:=REC.AMORT_ID;
    REC_PIPE.AMORT_IND:=REC.AMORT_IND;
    REC_PIPE.ATI:=REC.ATI;
    REC_PIPE.ATI_2:=REC.ATI_2;
    REC_PIPE.ATI_2_AMT:=REC.ATI_2_AMT;
    REC_PIPE.ATI_2_CCY_CD:=REC.ATI_2_CCY_CD;
    REC_PIPE.ATI_AMT:=REC.ATI_AMT;
    REC_PIPE.ATI_CCY_CD:=REC.ATI_CCY_CD;
    REC_PIPE.AVG_MTH_DUE_AMT:=REC.AVG_MTH_DUE_AMT;
    REC_PIPE.AVG_MTH_DUE_CCY_CD:=REC.AVG_MTH_DUE_CCY_CD;
    REC_PIPE.AVG_YTD_DUE_AMT:=REC.AVG_YTD_DUE_AMT;
    REC_PIPE.AVG_YTD_DUE_CCY_CD:=REC.AVG_YTD_DUE_CCY_CD;
    REC_PIPE.BAL_SHEET_EXP_AMT:=REC.BAL_SHEET_EXP_AMT;
    REC_PIPE.BAL_SHEET_EXP_AMT_IFRS:=REC.BAL_SHEET_EXP_AMT_IFRS;
    REC_PIPE.BAL_SHEET_EXP_CCY_CD:=REC.BAL_SHEET_EXP_CCY_CD;
    REC_PIPE.BAL_SHEET_EXP_CCY_CD_IFRS:=REC.BAL_SHEET_EXP_CCY_CD_IFRS;
    REC_PIPE.BAL_SHEET_EXP_EUR_AMT:=REC.BAL_SHEET_EXP_EUR_AMT;
    REC_PIPE.BAL_SHEET_EXP_EUR_AMT_IFRS:=REC.BAL_SHEET_EXP_EUR_AMT_IFRS;
    REC_PIPE.BEN_CCDB_ID:=REC.BEN_CCDB_ID;
    REC_PIPE.BEN_CD:=REC.BEN_CD;
    REC_PIPE.BEN_SRC_CD:=REC.BEN_SRC_CD;
    REC_PIPE.BOOK_CD:=REC.BOOK_CD;
    REC_PIPE.BOOK_TYPE_CD:=REC.BOOK_TYPE_CD;
    REC_PIPE.BOOK_VAL_AMT:=REC.BOOK_VAL_AMT;
    REC_PIPE.BOOK_VAL_AMT_IFRS:=REC.BOOK_VAL_AMT_IFRS;
    REC_PIPE.BOOK_VAL_CCY_CD:=REC.BOOK_VAL_CCY_CD;
    REC_PIPE.BOOK_VAL_CCY_CD_IFRS:=REC.BOOK_VAL_CCY_CD_IFRS;
    REC_PIPE.BOOK_VAL_US_GAAP_AMT:=REC.BOOK_VAL_US_GAAP_AMT;
    REC_PIPE.BRANCH_ID:=REC.BRANCH_ID;
    REC_PIPE.BRANCH_LOC_CD:=REC.BRANCH_LOC_CD;
    REC_PIPE.BS_COMPEN_CD:=REC.BS_COMPEN_CD;
    REC_PIPE.BUS_AREA_UBR_ID:=REC.BUS_AREA_UBR_ID;
    REC_PIPE.CA_CD:=REC.CA_CD;
    REC_PIPE.CAD_RISK_WEIGHT_PCT:=REC.CAD_RISK_WEIGHT_PCT;
    REC_PIPE.CASH_SETTLE_IND:=REC.CASH_SETTLE_IND;
    REC_PIPE.CLS_FLG:=REC.CLS_FLG;
    REC_PIPE.COB_DT:=REC.COB_DT;
    REC_PIPE.COL_AGMENT_SRC_CD:=REC.COL_AGMENT_SRC_CD;
    REC_PIPE.CONSOLIDATION_PCT:=REC.CONSOLIDATION_PCT;
    REC_PIPE.CONTRACT_AMT:=REC.CONTRACT_AMT;
    REC_PIPE.CONTRACT_COUNT:=REC.CONTRACT_COUNT;
    REC_PIPE.COST_UNSEC_WORKOUT_AMT:=REC.COST_UNSEC_WORKOUT_AMT;
    REC_PIPE.CPTY_CCDB_ID:=REC.CPTY_CCDB_ID;
    REC_PIPE.CPTY_CD:=REC.CPTY_CD;
    REC_PIPE.CPTY_LONG_NAME:=REC.CPTY_LONG_NAME;
    REC_PIPE.CPTY_SRC_PROXY_UBR_ID:=REC.CPTY_SRC_PROXY_UBR_ID;
    REC_PIPE.CPTY_TYPE_CD:=REC.CPTY_TYPE_CD;
    REC_PIPE.CPTY_UBR_ID:=REC.CPTY_UBR_ID;
    REC_PIPE.CREDIT_LINE_NET_IND:=REC.CREDIT_LINE_NET_IND;
    REC_PIPE.CRES_SYS_ID:=REC.CRES_SYS_ID;
    REC_PIPE.CTRY_RISK_PROVISION_BAL_AMT:=REC.CTRY_RISK_PROVISION_BAL_AMT;
    REC_PIPE.CUR_NOTIONAL_AMT:=REC.CUR_NOTIONAL_AMT;
    REC_PIPE.CUR_NOTIONAL_CCY_CD:=REC.CUR_NOTIONAL_CCY_CD;
    REC_PIPE.CUR_NOTIONAL_CCY_CD_IFRS:=REC.CUR_NOTIONAL_CCY_CD_IFRS;
    REC_PIPE.CUR_NOTIONAL_AMT_IFRS:=REC.CUR_NOTIONAL_AMT_IFRS;
    REC_PIPE.DB_ENTITY_TRANSFER_ASSETS_CD:=REC.DB_ENTITY_TRANSFER_ASSETS_CD;
    REC_PIPE.DEAL_TYPE_CD:=REC.DEAL_TYPE_CD;
    REC_PIPE.DECOMPOSITION_IDENTIFIER:=REC.DECOMPOSITION_IDENTIFIER;
    REC_PIPE.DEF_LOAN_FEE_IFRS:=REC.DEF_LOAN_FEE_IFRS;
    REC_PIPE.DEF_LOAN_FEE_USGAAP:=REC.DEF_LOAN_FEE_USGAAP;
    REC_PIPE.DELIVERY_DT:=REC.DELIVERY_DT;
    REC_PIPE.DERIV_NOT_DT:=REC.DERIV_NOT_DT;
    REC_PIPE.DERIV_NOT_IND:=REC.DERIV_NOT_IND;
    REC_PIPE.DESK:=REC.DESK;
    REC_PIPE.DIVISION_UBR_ID:=REC.DIVISION_UBR_ID;
    REC_PIPE.ENTITY_CCDB_ID:=REC.ENTITY_CCDB_ID;
    REC_PIPE.FAC_CD:=REC.FAC_CD;
    REC_PIPE.FAC_LIMIT_CD:=REC.FAC_LIMIT_CD;
    REC_PIPE.FAC_LIMIT_SRC_CD:=REC.FAC_LIMIT_SRC_CD;
    REC_PIPE.FAC_SRC_CD:=REC.FAC_SRC_CD;
    REC_PIPE.FAIR_VAL_CD_IFRS:=REC.FAIR_VAL_CD_IFRS;
    REC_PIPE.FED_CLASS_CD:=REC.FED_CLASS_CD;
    REC_PIPE.FIRST_RISK_PROVISION_DT:=REC.FIRST_RISK_PROVISION_DT;
    REC_PIPE.FV_IMP_LOSS_CRED_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_CCY_IFRS;
    REC_PIPE.FV_IMP_LOSS_CRED_IFRS:=REC.FV_IMP_LOSS_CRED_IFRS;
    REC_PIPE.FV_IMP_LOSS_CRED_YTD_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_CCY_IFRS;
    REC_PIPE.FV_IMP_LOSS_CRED_YTD_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_IFRS;
    REC_PIPE.GEN_RISK_PROVISION_BAL_AMT:=REC.GEN_RISK_PROVISION_BAL_AMT;
    REC_PIPE.GL_PROFIT_CENTRE:=REC.GL_PROFIT_CENTRE;
    REC_PIPE.GLOBAL_GL_CD:=REC.GLOBAL_GL_CD;
    REC_PIPE.IFRS_POSITION:=REC.IFRS_POSITION;
    REC_PIPE.IFRS_POSITION_AGGR:=REC.IFRS_POSITION_AGGR;
    REC_PIPE.IMP_DT:=REC.IMP_DT;
    REC_PIPE.IMP_METHOD_CD:=REC.IMP_METHOD_CD;
    REC_PIPE.INT_COMPEN_CD:=REC.INT_COMPEN_CD;
    REC_PIPE.INTER_IND:=REC.INTER_IND;
    REC_PIPE.INTERCO_IND:=REC.INTERCO_IND;
    REC_PIPE.INTERCO_IND_IFRS:=REC.INTERCO_IND_IFRS;
    REC_PIPE.LOAN_PUR_FAIR_VAL_ADJ_AMT:=REC.LOAN_PUR_FAIR_VAL_ADJ_AMT;
    REC_PIPE.LOCAL_GL_CD:=REC.LOCAL_GL_CD;
    REC_PIPE.LOWEST_LEVEL_UBR_ID:=REC.LOWEST_LEVEL_UBR_ID;
    REC_PIPE.LTD_FEES_TO_PRINCIPAL_AMT:=REC.LTD_FEES_TO_PRINCIPAL_AMT;
    REC_PIPE.MA_CD:=REC.MA_CD;
    REC_PIPE.MA_SPL_NOTE:=REC.MA_SPL_NOTE;
    REC_PIPE.MA_SRC_CD:=REC.MA_SRC_CD;
    REC_PIPE.MA_TYPE_CD:=REC.MA_TYPE_CD;
    REC_PIPE.MAN_LINK_ID:=REC.MAN_LINK_ID;
    REC_PIPE.MASTER_MA_CD:=REC.MASTER_MA_CD;
    REC_PIPE.MATURITY_DT:=REC.MATURITY_DT;
    REC_PIPE.MAX_OUT_AMT:=REC.MAX_OUT_AMT;
    REC_PIPE.MAX_OUT_CCY_CD:=REC.MAX_OUT_CCY_CD;
    REC_PIPE.MTM_AMT:=REC.MTM_AMT;
    REC_PIPE.MTM_AMT_IFRS:=REC.MTM_AMT_IFRS;
    REC_PIPE.MTM_CCY_CD:=REC.MTM_CCY_CD;
    REC_PIPE.MTM_CCY_CD_IFRS:=REC.MTM_CCY_CD_IFRS;
    REC_PIPE.NEW_RISK_PROVISION_AMT:=REC.NEW_RISK_PROVISION_AMT;
    REC_PIPE.NON_PERF_IND:=REC.NON_PERF_IND;
    REC_PIPE.NON_PERF_RCV_INT_AMT:=REC.NON_PERF_RCV_INT_AMT;
    REC_PIPE.OPT_TYPE_CD:=REC.OPT_TYPE_CD;
    REC_PIPE.ORIG_NOTIONAL_AMT:=REC.ORIG_NOTIONAL_AMT;
    REC_PIPE.ORIG_NOTIONAL_CCY_CD:=REC.ORIG_NOTIONAL_CCY_CD;
    REC_PIPE.ORIG_TRN_CD:=REC.ORIG_TRN_CD;
    REC_PIPE.ORIG_TRN_SRC_CD:=REC.ORIG_TRN_SRC_CD;
    REC_PIPE.OTHER_CUR_NOTIONAL_AMT:=REC.OTHER_CUR_NOTIONAL_AMT;
    REC_PIPE.OTHER_CUR_NOTIONAL_CCY_CD:=REC.OTHER_CUR_NOTIONAL_CCY_CD;
    REC_PIPE.OTHER_ORIG_NOTIONAL_AMT:=REC.OTHER_ORIG_NOTIONAL_AMT;
    REC_PIPE.OTHER_ORIG_NOTIONAL_CCY_CD:=REC.OTHER_ORIG_NOTIONAL_CCY_CD;
    REC_PIPE.OVERDUE_AMT:=REC.OVERDUE_AMT;
    REC_PIPE.OVERDUE_CCY_CD:=REC.OVERDUE_CCY_CD;
    REC_PIPE.OVERDUE_DAY_COUNT:=REC.OVERDUE_DAY_COUNT;
    REC_PIPE.PAY_CONTRACT_AMT:=REC.PAY_CONTRACT_AMT;
    REC_PIPE.PAY_CONTRACT_CCY_CD:=REC.PAY_CONTRACT_CCY_CD;
    REC_PIPE.PAY_FWD_AMT:=REC.PAY_FWD_AMT;
    REC_PIPE.PAY_FWD_CCY_CD:=REC.PAY_FWD_CCY_CD;
    REC_PIPE.PAY_INT_INTERVAL:=REC.PAY_INT_INTERVAL;
    REC_PIPE.PAY_INT_RATE:=REC.PAY_INT_RATE;
    REC_PIPE.PAY_INT_RATE_TYPE_CD:=REC.PAY_INT_RATE_TYPE_CD;
    REC_PIPE.PAY_NEXT_FIX_CPN_DT:=REC.PAY_NEXT_FIX_CPN_DT;
    REC_PIPE.PAY_UL_SEC_TYPE_CD:=REC.PAY_UL_SEC_TYPE_CD;
    REC_PIPE.PAY_UL_ISS_CCDB_ID:=REC.PAY_UL_ISS_CCDB_ID;
    REC_PIPE.PAY_UL_MTM_AMT:=REC.PAY_UL_MTM_AMT;
    REC_PIPE.PAY_UL_MTM_CCY_CD:=REC.PAY_UL_MTM_CCY_CD;
    REC_PIPE.PAY_UL_SEC_CCY_CD:=REC.PAY_UL_SEC_CCY_CD;
    REC_PIPE.PAY_UL_SEC_CD:=REC.PAY_UL_SEC_CD;
    REC_PIPE.PCP_TRANSACTION_SK:=REC.PCP_TRANSACTION_SK;
    REC_PIPE.PROD_AREA_UBR_ID:=REC.PROD_AREA_UBR_ID;
    REC_PIPE.QUOTA_PART_AMT:=REC.QUOTA_PART_AMT;
    REC_PIPE.RCV_CONTRACT_AMT:=REC.RCV_CONTRACT_AMT;
    REC_PIPE.RCV_CONTRACT_CCY_CD:=REC.RCV_CONTRACT_CCY_CD;
    REC_PIPE.RCV_FWD_AMT:=REC.RCV_FWD_AMT;
    REC_PIPE.RCV_FWD_CCY_CD:=REC.RCV_FWD_CCY_CD;
    REC_PIPE.RCV_INT_RATE:=REC.RCV_INT_RATE;
    REC_PIPE.RCV_INT_RATE_TYPE_CD:=REC.RCV_INT_RATE_TYPE_CD;
    REC_PIPE.RCV_INT_INTERVAL:=REC.RCV_INT_INTERVAL;
    REC_PIPE.RCV_NEXT_FIX_CPN_DT:=REC.RCV_NEXT_FIX_CPN_DT;
    REC_PIPE.RCV_UL_ISS_CCDB_ID:=REC.RCV_UL_ISS_CCDB_ID;
    REC_PIPE.RCV_UL_MTM_AMT:=REC.RCV_UL_MTM_AMT;
    REC_PIPE.RCV_UL_MTM_CCY_CD:=REC.RCV_UL_MTM_CCY_CD;
    REC_PIPE.RCV_UL_SEC_CCY_CD:=REC.RCV_UL_SEC_CCY_CD;
    REC_PIPE.RCV_UL_SEC_CD:=REC.RCV_UL_SEC_CD;
    REC_PIPE.RCV_UL_SEC_TYPE_CD:=REC.RCV_UL_SEC_TYPE_CD;
    REC_PIPE.REC_SEC_AMT:=REC.REC_SEC_AMT;
    REC_PIPE.REC_SEC_CCY_CD:=REC.REC_SEC_CCY_CD;
    REC_PIPE.REC_UNSEC_AMT:=REC.REC_UNSEC_AMT;
    REC_PIPE.REC_UNSEC_CCY_CD:=REC.REC_UNSEC_CCY_CD;
    REC_PIPE.RECON_CD:=REC.RECON_CD;
    REC_PIPE.RECON_SRC_CD:=REC.RECON_SRC_CD;
    REC_PIPE.RECOV_AMT:=REC.RECOV_AMT;
    REC_PIPE.RECOVERY_FLAG:=REC.RECOVERY_FLAG;
    REC_PIPE.REGULATORY_NET_IND:=REC.REGULATORY_NET_IND;
    REC_PIPE.REL_RISK_PROVISION_AMT:=REC.REL_RISK_PROVISION_AMT;
    REC_PIPE.RESPONSIBLE_BRANCH_CCDB_ID:=REC.RESPONSIBLE_BRANCH_CCDB_ID;
    REC_PIPE.RESPONSIBLE_BRANCH_ID:=REC.RESPONSIBLE_BRANCH_ID;
    REC_PIPE.RESPONSIBLE_BRANCH_LOC_CD:=REC.RESPONSIBLE_BRANCH_LOC_CD;
    REC_PIPE.RESTRUCT_IND:=REC.RESTRUCT_IND;
    REC_PIPE.RISK_END_DT:=REC.RISK_END_DT;
    REC_PIPE.RISK_ENGINES_METHOD_USED:=REC.RISK_ENGINES_METHOD_USED;
    REC_PIPE.RISK_MITIGATING_PCT:=REC.RISK_MITIGATING_PCT;
    REC_PIPE.RISK_PROVISION_BAL_AMT:=REC.RISK_PROVISION_BAL_AMT;
    REC_PIPE.RISK_PROVISION_CCY_CD:=REC.RISK_PROVISION_CCY_CD;
    REC_PIPE.RISK_WRITE_OFF_AMT:=REC.RISK_WRITE_OFF_AMT;
    REC_PIPE.RISK_WRITE_OFF_LIFE_DT_AMT:=REC.RISK_WRITE_OFF_LIFE_DT_AMT;
    REC_PIPE.RT_BUS_AREA_UBR_ID:=REC.RT_BUS_AREA_UBR_ID;
    REC_PIPE.RT_CB_CCDB_ID:=REC.RT_CB_CCDB_ID;
    REC_PIPE.RT_COV_CD:=REC.RT_COV_CD;
    REC_PIPE.RT_COV_SRC_CD:=REC.RT_COV_SRC_CD;
    REC_PIPE.RT_COV_TYPE_CD:=REC.RT_COV_TYPE_CD;
    REC_PIPE.RT_COV_TYPE_CD_IFRS:=REC.RT_COV_TYPE_CD_IFRS;
    REC_PIPE.RT_TYPE_CD:=REC.RT_TYPE_CD;
    REC_PIPE.RT_TYPE_CD_IFRS:=REC.RT_TYPE_CD_IFRS;
    REC_PIPE.SENIORITY:=REC.SENIORITY;
    REC_PIPE.SETTLE_STATUS_ID:=REC.SETTLE_STATUS_ID;
    REC_PIPE.SETTLEMENT_CD:=REC.SETTLEMENT_CD;
    REC_PIPE.SETTLEMENT_DT:=REC.SETTLEMENT_DT;
    REC_PIPE.SOX_REF:=REC.SOX_REF;
    REC_PIPE.SPE_IND:=REC.SPE_IND;
    REC_PIPE.SPL_TREAT_IND_IFRS:=REC.SPL_TREAT_IND_IFRS;
    REC_PIPE.SRC_PROD_TYPE_CD:=REC.SRC_PROD_TYPE_CD;
    REC_PIPE.SRC_PROD_TYPE_CD_IFRS:=REC.SRC_PROD_TYPE_CD_IFRS;
    REC_PIPE.SRC_PROXY_UBR_CD:=REC.SRC_PROXY_UBR_CD;
    REC_PIPE.START_DT:=REC.START_DT;
    REC_PIPE.STRATEGIC_LEND_IND:=REC.STRATEGIC_LEND_IND;
    REC_PIPE.STRIKE_FWD_FUT_PRICE_AMT:=REC.STRIKE_FWD_FUT_PRICE_AMT;
    REC_PIPE.STRIKE_FWD_FUT_PRICE_CCY_CD:=REC.STRIKE_FWD_FUT_PRICE_CCY_CD;
    REC_PIPE.TERMINATION_LOAN_DT:=REC.TERMINATION_LOAN_DT;
    REC_PIPE.TRAD_ASSET_CD_IFRS:=REC.TRAD_ASSET_CD_IFRS;
    REC_PIPE.TRADE_DT:=REC.TRADE_DT;
    REC_PIPE.TRADE_ENTITY_CCDB_ID:=REC.TRADE_ENTITY_CCDB_ID;
    REC_PIPE.TRADE_ENTITY_LOC_CD:=REC.TRADE_ENTITY_LOC_CD;
    REC_PIPE.TRADE_RELATED_IND:=REC.TRADE_RELATED_IND;
    REC_PIPE.TRADE_STATUS:=REC.TRADE_STATUS;
    REC_PIPE.TRADING_ENTITY_LOC_CD:=REC.TRADING_ENTITY_LOC_CD;
    REC_PIPE.TRAN_MATCH_CD:=REC.TRAN_MATCH_CD;
    REC_PIPE.TRN_CD:=REC.TRN_CD;
    REC_PIPE.TRN_LINK_CD:=REC.TRN_LINK_CD;
    REC_PIPE.TRN_SRC_CD:=REC.TRN_SRC_CD;
    REC_PIPE.TRN_TYPE_CD:=REC.TRN_TYPE_CD;
    REC_PIPE.TRN_VERSION:=REC.TRN_VERSION;
    REC_PIPE.UL_DELIVERY_DT:=REC.UL_DELIVERY_DT;
    REC_PIPE.UL_MATURITY_DT:=REC.UL_MATURITY_DT;
    REC_PIPE.UNDLY_ISS_NAME:=REC.UNDLY_ISS_NAME;
    REC_PIPE.UNEARNED_INCOME_CCY_CD:=REC.UNEARNED_INCOME_CCY_CD;
    REC_PIPE.UNEARNED_INCOME_DIS_LOAN_AMT:=REC.UNEARNED_INCOME_DIS_LOAN_AMT;
    REC_PIPE.US_GAAP_POSITION_AGGR:=REC.US_GAAP_POSITION_AGGR;
    REC_PIPE.VALUATION_DT:=REC.VALUATION_DT;
    REC_PIPE.XCHG_CTRY_CD:=REC.XCHG_CTRY_CD;
    REC_PIPE.YEAR01_NOTIONAL_AMT:=REC.YEAR01_NOTIONAL_AMT;
    REC_PIPE.YEAR02_NOTIONAL_AMT:=REC.YEAR02_NOTIONAL_AMT;
    REC_PIPE.YEAR03_NOTIONAL_AMT:=REC.YEAR03_NOTIONAL_AMT;
    REC_PIPE.YEAR04_NOTIONAL_AMT:=REC.YEAR04_NOTIONAL_AMT;
    REC_PIPE.YEAR05_NOTIONAL_AMT:=REC.YEAR05_NOTIONAL_AMT;
    REC_PIPE.YEAR06_NOTIONAL_AMT:=REC.YEAR06_NOTIONAL_AMT;
    REC_PIPE.YEAR07_NOTIONAL_AMT:=REC.YEAR07_NOTIONAL_AMT;
    REC_PIPE.YEAR08_NOTIONAL_AMT:=REC.YEAR08_NOTIONAL_AMT;
    REC_PIPE.YEAR09_NOTIONAL_AMT:=REC.YEAR09_NOTIONAL_AMT;
    REC_PIPE.YEAR10_NOTIONAL_AMT:=REC.YEAR10_NOTIONAL_AMT;
    REC_PIPE.YTD_PL_TRADE_AMT:=REC.YTD_PL_TRADE_AMT;
    REC_PIPE.FCL_VALIDATED_IND:=REC.FCL_VALIDATED_IND;
    REC_PIPE.FCL_EXCLUDED_IND:=REC.FCL_EXCLUDED_IND;
    REC_PIPE.FCL_SOURCE_SYSTEM:=REC.FCL_SOURCE_SYSTEM;
    REC_PIPE.FCL_CREATE_TIMESTAMP:=REC.FCL_CREATE_TIMESTAMP;
    REC_PIPE.FCL_UPDATE_TIMESTAMP:=REC.FCL_UPDATE_TIMESTAMP;
    REC_PIPE.FCL_TRADE_LOAD_DATE:=REC.FCL_TRADE_LOAD_DATE;
    REC_PIPE.FCL_VALUATION_LOAD_DATE:=REC.FCL_VALUATION_LOAD_DATE;
    REC_PIPE.FCL_MATRIX_TRADE_TYPE:=REC.FCL_MATRIX_TRADE_TYPE;
    REC_PIPE.PCP_GCDS_REVISION:=REC.PCP_GCDS_REVISION;
    REC_PIPE.FCL_UTP_BOOK_CD:=REC.FCL_UTP_BOOK_CD;
    REC_PIPE.FCL_MIS_RISK_BOOK_CD:=REC.FCL_MIS_RISK_BOOK_CD;
    REC_PIPE.ALD_STATUS:=REC.ALD_STATUS;
    REC_PIPE.FCAT_OPERATION:=REC.FCAT_OPERATION;
    REC_PIPE.INTERNAL_INTRA_IND_IFRS:=REC.INTERNAL_INTRA_IND_IFRS;
    REC_PIPE.FCL_USAGE_IND:=REC.FCL_USAGE_IND;
    REC_PIPE.QUICK:=REC.QUICK;
    REC_PIPE.SEDOL:=REC.SEDOL;
    REC_PIPE.CUSIP:=REC.CUSIP;
    REC_PIPE.ISIN:=REC.ISIN;
    REC_PIPE.QUANTITY:=REC.QUANTITY;
    REC_PIPE.RIC:=REC.RIC;
    REC_PIPE.DESCRIPTION:=REC.DESCRIPTION;
    REC_PIPE.RESET_DATE:=REC.RESET_DATE;
    REC_PIPE.PRICE:=REC.PRICE;
    REC_PIPE.EXCHANGERATE:=REC.EXCHANGERATE;
    REC_PIPE.PARA_PROD_TYPE_ID:=REC.PARA_PROD_TYPE_ID;
    REC_PIPE.EFF_INT_RATE:=REC.EFF_INT_RATE;
    REC_PIPE.ORIG_FEE_UNREALISED_AMT:=REC.ORIG_FEE_UNREALISED_AMT;
    REC_PIPE.ASSET_TYPE:=REC.ASSET_TYPE;
    REC_PIPE.IMP_IND_IFRS:=REC.IMP_IND_IFRS;
    REC_PIPE.NOT_AMT_REDEMPTION_TO_1YR:=REC.NOT_AMT_REDEMPTION_TO_1YR;
    REC_PIPE.NOT_AMT_REDEMPTION_TO_5YR:=REC.NOT_AMT_REDEMPTION_TO_5YR;
    REC_PIPE.NOT_AMT_REDEMPTION_OVER_5YR:=REC.NOT_AMT_REDEMPTION_OVER_5YR;
    REC_PIPE.CASH_LTD:=REC.CASH_LTD;
    REC_PIPE.CASH_LTD_CCY:=REC.CASH_LTD_CCY;
    REC_PIPE.FCL_FACILITY_SK:=REC.FCL_FACILITY_SK;
    REC_PIPE.DILUTION_RISK_CRITERIA:=REC.DILUTION_RISK_CRITERIA;
    REC_PIPE.FCL_RMS_RUNID:=REC.FCL_RMS_RUNID;
    REC_PIPE.BSTYPE:=REC.BSTYPE;
    REC_PIPE.YTD_ACCR_DIV:=REC.YTD_ACCR_DIV;
    REC_PIPE.YTD_DIV:=REC.YTD_DIV;
    REC_PIPE.ACC_ADJ_YTD:=REC.ACC_ADJ_YTD;
    REC_PIPE.FV_RLZD_PL:=REC.FV_RLZD_PL;
    REC_PIPE.ITD_PL:=REC.ITD_PL;
    REC_PIPE.YTD_RLZD_PL:=REC.YTD_RLZD_PL;
    REC_PIPE.YTD_UNRLZD_PL:=REC.YTD_UNRLZD_PL;
    REC_PIPE.TRN_BAS_LGD:=REC.TRN_BAS_LGD;
    REC_PIPE.TRAD_YTD_RLZD_PL:=REC.TRAD_YTD_RLZD_PL;
    REC_PIPE.TRAD_YTD_UNRLZD_PL:=REC.TRAD_YTD_UNRLZD_PL;
    REC_PIPE.UNADJUSTED_PV:=REC.UNADJUSTED_PV;
    REC_PIPE.UNADJUSTED_REALISED_PL:=REC.UNADJUSTED_REALISED_PL;
    REC_PIPE.UNADJUSTED_UNREALISED_PL:=REC.UNADJUSTED_UNREALISED_PL;
    REC_PIPE.GRC_PROD_TYPE_ID:=REC.GRC_PROD_TYPE_ID;
    REC_PIPE.GRC_PROD_TYPE_ID_IFRS:=REC.GRC_PROD_TYPE_ID_IFRS;
    REC_PIPE.CUR_FEE:=REC.CUR_FEE;
    REC_PIPE.SEC_IND:=REC.SEC_IND;
    REC_PIPE.INVEST_ASSETS_PORT:=REC.INVEST_ASSETS_PORT;
    REC_PIPE.RISK_PROVISION_START_BAL_AMT:=REC.RISK_PROVISION_START_BAL_AMT;
    REC_PIPE.GEN_RISK_PRV_START_BAL_AMT:=REC.GEN_RISK_PRV_START_BAL_AMT;
    REC_PIPE.GEN_RISK_PROVISION_NEW:=REC.GEN_RISK_PROVISION_NEW;
    REC_PIPE.GEN_RISK_PROVISION_REL:=REC.GEN_RISK_PROVISION_REL;
    REC_PIPE.ACQUIRED_IND:=REC.ACQUIRED_IND;
    REC_PIPE.CRED_NET_MNA:=REC.CRED_NET_MNA;
    REC_PIPE.SEC_IFRS_VUE_ADJ:=REC.SEC_IFRS_VUE_ADJ;
    REC_PIPE.YEAR00_NOTIONAL_AMT:=REC.YEAR00_NOTIONAL_AMT;
    REC_PIPE.MAX_OVERDUE_DAYS:=REC.MAX_OVERDUE_DAYS;
    REC_PIPE.MIS_CD:=REC.MIS_CD;
    REC_PIPE.MULTINAME_POOL_SK:=REC.MULTINAME_POOL_SK;
    REC_PIPE.MULTINAME_CHUNK_REVISION_SK:=REC.MULTINAME_CHUNK_REVISION_SK;
    REC_PIPE.MTRX_CALC_CNTRL_EPE:=REC.MTRX_CALC_CNTRL_EPE;
    REC_PIPE.MTRX_CALC_CNTRL_PFE:=REC.MTRX_CALC_CNTRL_PFE;
    REC_PIPE.FCL_TE_VALIDATED_IND:=REC.FCL_TE_VALIDATED_IND;
    REC_PIPE.PCP_TE_DYNAMIC_KEY:=REC.PCP_TE_DYNAMIC_KEY;
    REC_PIPE.AVG_COST:=REC.AVG_COST;
    REC_PIPE.SEC_LONG_NAME:=REC.SEC_LONG_NAME;
    REC_PIPE.ISS_CTRY_CD:=REC.ISS_CTRY_CD;
    REC_PIPE.RISK_REPORTING_UBR:=REC.RISK_REPORTING_UBR;
    REC_PIPE.RISK_COVERING_BRANCH_CCDB:=REC.RISK_COVERING_BRANCH_CCDB;
    REC_PIPE.CLEARING_STATUS:=REC.CLEARING_STATUS;
    REC_PIPE.FCL_CPTY_SK:=REC.FCL_CPTY_SK;
    REC_PIPE.STRGRP:=REC.STRGRP;
    REC_PIPE.OPEN_ENDED_FLAG:=REC.OPEN_ENDED_FLAG;
    REC_PIPE.AVAILABILITY_IND:=REC.AVAILABILITY_IND;
    REC_PIPE.ESCRW_FLG:=REC.ESCRW_FLG;
    REC_PIPE.ESTABLISHED_RELP_FLG:=REC.ESTABLISHED_RELP_FLG;
    REC_PIPE.GOV_GTY_AMT:=REC.GOV_GTY_AMT;
    REC_PIPE.BUBA_CTRY_ID:=REC.BUBA_CTRY_ID;
    REC_PIPE.GOV_GTY_CTRY_CD:=REC.GOV_GTY_CTRY_CD;
    REC_PIPE.INTERNET_DPST_FLG:=REC.INTERNET_DPST_FLG;
    REC_PIPE.LAST_ACTIVITY_DT:=REC.LAST_ACTIVITY_DT;
    REC_PIPE.NOTICE_PERIOD_QTY:=REC.NOTICE_PERIOD_QTY;
    REC_PIPE.OPR_RELP_FLG:=REC.OPR_RELP_FLG;
    REC_PIPE.SIG_WD_PENALTY_FLG:=REC.SIG_WD_PENALTY_FLG;
    REC_PIPE.TRN_ACT_FLG:=REC.TRN_ACT_FLG;
    PIPE ROW(REC_PIPE);
    END LOOP;
    the Stored procedre returns REC_PIPE.
    I thins this could be not efficient enough...
    What do you think?

  • Best way to store big amount of data

    Hi, i need to store a big amount of data, written in a txt its size is almost 12 mg, anyway it depends on the computer it runs, beacause what i want to store is all the shared files in a computer.
    Which is the best way to store it? Array string? textfile? List? I don�t need the data after the app close.
    Thanks

    Well, then which is the best solution? LinkedList or
    Tree? i only need to store the full path.
    What i didn�t say, my fail, is that i need to search
    for a file name once i have stored them...For searching, LinkedList will be very slow if it's very large. I think the same is true of javax.swing .tree.DefaultTreeModel, which is the JDK's only tree implementation. I don't know what Jakarta-collections has - it's possible they have a tree that offers fast searching. If you want to stick to the standard Java libraries, you'll want a Set for fast searching. TreeSet keeps the entries in sorted order. If you also need to display them as a tree, you can keep them in both a Set and a tree. If you don't have enough memory to do that, then displaying the whole tree isn't going to be useful to the user anyway, so rethink your goal.

  • Handle big amount of data

    Hello,
    I have to analyse a great amount of data (more than 20MByte), that I read from a logfile. I can't split these data into smaller parts because some of my analysis-methods need all data (regression,....).
    Are there any tricks for LabVIEW (5.0.1), how to handle big amounts of data?
    hans

    You might be able to do as you would like. If analysing process needs
    all amont of data,
    the whole process takes a couple of minutes but no problem. It gives you
    no information
    on the way of process like as hanging, so using "read files", not "read
    from spread
    sheet files", is better to have confirming process including the graphic
    monitor involved
    in the analysing vi that you like to build.
    Thanks in advance,
    Tom
    hans wrote:
    > Hello,
    >
    > I have to analyse a great amount of data (more than 20MByte), that I
    > read from a logfile. I can't split these data into smaller parts
    > because some of my analysis-methods need all data (regression,....).
    >
    > Are there any tricks for LabVIEW (5.0.1), how to handle big amounts of
    > data?
    >
    > hans

  • Can you cluster Coherence over data centers?

    We're currently running two separate Coherence clusters in different data centers. One is prod, the other DR.
    Would it be possible to cluster the nodes from each of these to create one cluster spanning both data centers? Then in a failover scenario the data would already be available.
    I know Coherence nodes heartbeat to one another to retain cluster membership and that there is a TTL setting to determine packet life. Would have nodes in different data centers result in heartbeats being missed or TTLs killing packets?
    Has anyone had any success with this?

    Coherence performance is related to the latency between nodes. Having one cluster spread over 2 data centers could harm performance (some timeouts could have to be changed to prevent nodes from data center A to claim another node in datacenter B is out of reach/possibly dead).
    When you lose network connectivity between the 2 data centers (note i'm not saying "if you lose connectivity". It WILL happen), you're welcome into the "split brain world", each half of the grid believing the other is dead and claiming to be the "master". And thus, if you have data replicated on N nodes, the master/backups are redispatched all over each datacenter, harming performance for a few minutes (the timing depending of course on many parameters...). And of course the data will no longer be synchronized between the 2 data centers. The quorum has to be thought of, and stuff like that...
    I might be wrong, but AFAIK I'd rather have 2 separate clusters. I believe 12.1 has new features to replicate data the the master grid to the DR one, I have not been through all the new documentation.

  • Extending VLAN across Data centers

    I hope you can help, I have 2 data centers connected via a L3 10gb (dark fiber) now I have a few more fiber strands available between the 2 data centers; so for Disaster Recovery and server clustering (requiring same subnet) does it make sense to extend certain vlans across using these extra fiber strands or is it best practice to keep the layer 3 separation, thanks in advance!

    Borman
    It does make sense in terms of clustering. Not sure exactly what you mean in terms of disaster recovery, that really depends on your topology/addressing.
    Basically i would route where you can and extend L2 when you have to. Be aware you are extending L2 between data centres and tha brings STP issues. Obvioulsy make sure you only allow the vlans you need on this link and route all else.
    There are other ways to extend a L2 vlan across a L3 link - L2TPv3 springs to mind.
    Jon

  • ASA In Data Centers, why not routed mode?

    Hi Guys,
    As i can see, Cisco is recommending for the ASAs to be in transparent mode in data centers, my question, why not routed mode?
    How to decide? what is the problem in having the routing on ASA?
    I know that transparent mode is easier to place, but in my case it is new design and i want to use the interface vlans on the ASA not core. so the gateway of each server will be the ASA.
    what is the problem here? why it is not recommended?
    I'm using ASA clustering as well over two DCs.
    In Cisco links they explain why to use Transparent mode, but i couldn't find what is the problems/limitation in using routed mode?
    Any clue?
    Thanks & Regards,
    Rami

    but in my case it is new design and i want to use the interface vlans on the ASA not core. so the gateway of each server will be the ASA.
    If that's the case use routed mode on your ASA.
    Cisco's design docs are a great place to start but there is nothing that says you have to follow them to the letter, you modify them to fit with what you need.
    Bear in mind as well that it's not an either or choice. With contexts you can have some in transparent mode and some in routed mode so you have flexibility.
    I don't know what design guides you are referring to but it may be that they include some L2 features eg.
    a long while back we wanted to RRI (Reverse Route Injection) from a CSM load balancer that was behind a firewall. For it to work the CSM had to be L2 adjacent to the 6500 which meant you couldn't use the FWSM in L3 mode.
    Not saying you want to do that but it is an example of where other parts of the design can dictate how you run your firewalls.
    Jon

  • Office Web Apps Farm Across Multiple Data Centers?

    I have not been able to find any definitive information about this but the article below seems to suggest what I have in mind is not recommended.  I am not sure about supported.
    "Stick to one data center.  Servers in an Office Web Apps Server farm must be in the same data center. Don’t distribute them geographically. Generally you need only one farm, unless you have security needs
    that require an isolated network that has its own Office Web Apps Server farm."
    http://technet.microsoft.com/en-us/library/jj219435.aspx#topology
    What I have is two very well connected data centers located in the same metro area.  We will be deploying a Lync EE pool at each site and use pool pairing for DR.  What I am wondering is should I:
    Create a single Office Web Apps farm with the server from each data center as members?
    Create a farm in each site with a single member, but both farms sharing the same URL?
    Create a farm in each site with a single member, but both farms have different names.  This seems unnecessarily ugly, but throwing it out there.
    Since Lync is using Office Web Apps in read only mode the question is different than if SharePoint were involved.  However, I can't rule out this farm also being used for SharePoint down the road.
    The LB/RP device of choice is Citrix NetScaler.  Another thought I had is can that be configured so incoming requests for Office Web Apps at each data center can prioritize traffic to the server or farm within that data center?  If that is unavailable
    then switch to the server at the other data center?
    Thanks.

    Hi,
    An Office Web Apps farm can be deployed to provide functionality for multiple sites.
    Also you can deploy one Web Apps farm on each site.
    So I think you can choose to deploy with the option one and three as you said.
    Here is a case about deploying Lync deploy Office Web Apps server may help you:
    http://social.technet.microsoft.com/Forums/lync/en-US/7e67bacf-4895-4bdb-95b8-0aff8a0c575f/geographical-placement-of-office-web-app-servers?forum=lyncdeploy
    Best Regards,
    Eason Huang
    Eason Huang
    TechNet Community Support

  • Need suggestion for ISE distributed deployment model in two different data centers along with public certificate for HTTPS

    Hi Experts,
    I am bit confused about ISE distributed deployment model .
    I have two data centers one is DC & other one is as a DR I have  requirement of guest access service implementation using CWA and get public certificate for HTTPS to avoid certificate error on client devices :
    how do i deploy ISE persona for HA in this two data centers
    After reading cisco doc , understood that we can have two PAN ( Primary in DC  & Secondary in DR ) like wise for MnT (Monitoring will be as same as PAN ) however I can have 5 PSN running in secondary i.e. in DR ISE however I have confusion about HA for PSN .. since we have all PSN in secondary , it would not work for HA if it fails
    Can anybody suggest me the best deployment solution for this scenario ?
    Another doubt about public certificate :
     Public Certificate: The ISE domain must be a registered or part of a registered domain name on the Internet. for that I need Domain name being used from customer .
    Please do correct me if I am wrong about certificate understanding :
    since Guest will be the outside users , we can not use certificate from internal CA , we need to get the certificate from service provider and install the same in both the ISE servers
    Can anybody explain the procedure to opt the public certificate for HTTPS from service provider ? And how do i install it in both the ISE servers ?

    Hi there. Let me try answering your questions:
    PSN HA: The PSNs are not configured as "primary" or "secondary" inside your ISE deployment. They are just PSN nodes as far as ISE is concerned. Instead, inside your NADs (In your case WLCs) you can specify which PSN is primary, which one is secondary, etc. You can accomplish this by:
    1. Defining all PSN nodes as AAA radius servers inside the WLC
    2. Then under the SSID > AAA Servers Tab, you can list the AAA servers in the order that you prefer. As a result, the WLC will always use the first server listed until that server fails/gets reloaded, etc. 
    3. As a result, you can have one WLC or SSID prefer PSN server A (located in primary DC) while a second WLC or SSID prefer PSN server B (located in backup DC)
    Last but not the least, you could also place PSNs behind a load balancer and that way the traffic would be equally distributed between multiple PSNs. However, the PSN nodes must be Layer 2 adjacent, which is probably not the case if they are located in two different Data Centers
    Certificates: Yes, you would want to get a public certificate to service the guest portal. Getting a public/well known certificate would ensure that most devices out there would trust the CA that signed your ISE certificate. For instance, VeriSign, GoDaddy, Entrust are some of the ones out there that would work just fine. On the other hand, if you use a certificate that was signed by your internal CA, then things would be fine for your internal endpoints that trust your internal CA but for any outsiders (Guests, contractors, etc) that do not trust and do not know who your internal CA is would get a certificate error when being redirected to the ISE guest portal. This in general is only a "cosmetic" issue and if the users click "continue" and add your CA as a trusted authority, the guest page would load and the session would work. However, most users out there would not feel safe to proceed and you will most likely get a lot of calls to your helpdesk :)
    I hope this helps!
    Thank you for rating helpful posts!

  • Guest N+1 redundancy & load balancing in seperate data centers

    I need assistance in aquiring documentation to setup N+1 redundancy & load balancing between two seperate guest anchor controllers installed in seperate data centers. Can you explaing how it should be setup or point me in the right direction for documentation? If you can't point me in the right direction to aquire documentation; can you answer the following questions?
    1) How do I setup my mobility groups on my guest anchor controllers installed in the DMZ? Should both guest anchor's be in the same mobility group.
    2) Do both guest anchors share the same virtual IP or do they need to be seperate (DMZ01 - 1.1.1.1 / DMZ02 - 2.2.2.2)? I think seperate!
    3) Are there any configuration parameters on the guest anchors for load balancing?
    4) Do either on of the guest anchors need to be setup as a master controller? I'm not sure?
    5) Are there any configuration parameters on the foreign controllers for load balancing?
    6) How do I setup my foreign controllers? Should both guest controllers be added to the mobility group on the foreigh controller? I would think both of them would be added to the foreign controller mobility group.
    7) Should both guest anchors be added as an anchor on the WLAN? I would think both controllers would need to be added as anchors under the WLAN!
    8) Am I missing anything here? This is how I think it should logically work?
    Thanks,
    Gordon

    I need to elaborate on my questions:
    1) Do both of my guest DMZ anchors need to be in a seperate mobility group on their own or can the guest anchors be in completely seperate mobility groups? All 100 + foreign controllers are in seperate mobility groups.
    I) Example #1: Guest anchor number 1 (Mobility group: DMZ) / Guest anchor number 2 (Mobility group: DMZ)
    II) Example #2: Guest anchor number 1 (Mobility group: DMZ01) / Guest anchor number 2 (Mobility group: DMZ02)
    2) Do both guest anchor controllers have to be configured with seperate virtual IP's or do they share the same address?
    I) Follow up to this question: I want to register the DMZ controllers with our DNS servers so that my clients receive a name when authenticating through my customized webauth. I am currently using 1.1.1.1 as the virtual address and I'm pretty sure this is the address I need to register with my external DNS server. My question is this. Does the address I use for the virtual interface matter? 1.1.1.1 is not a valid address with my network. Do I need to assign a valid address registered with my network if I'm going to add this address to my external DNS servers?
    3) No change to my original question.
    4) No change to my original question.
    5) No change to my original question. I have run into Cisco documentation that mentions guest anchor load balancing, but the documentation is very vague. I'd love to be able to load balance as the network group wants to limit my guest traffic to the internet. I could double my pipe if I could load balance the guest anchors.
    6) No change to my original question, but the answer to question one is key to the setup of my foreign controllers.
    7) Elaboration: Should both guest controllers be added as an anchor under the WLAN on the foreign controllers? I would think both of them would be added.
    8) No change:
    9) Should my secondary guest controller be added as an anchor on the WLAN of the primary guest DMZ controller and visa versa?
    Can my Cisco expert answer this or do I need to open a TAC case?
    Thanks,
    Gordon Shelhon
    SR. Wireless Services Engineer
    Company: Not specified

  • Server Load-balancing Across Two Data centers on Layer 3

    Hi,
    I have a customer who would like to load balance two Microsoft Exchange 2010 CAS Servers which are residing across two data centers.
    Which is the best solution for this? Cisco ACE or Cisco ACE GSS or both?

    I would go with source natting the clients ip addresses, so that return traffic from the servers is routed correctly.
    It saves you the trouble with maintaining PBR as well.
    Source NAT can be done on the ACE, by applying the configuration to either the load balancing policy, or adding the configuration to the class-map entries in the multi-match policy.
    Cheers,
    Søren
    Sent from Cisco Technical Support iPad App

  • Big big problems using Generics, BeanInfo and Introspector

    I'm having a big big problem with Introspector class. Let me setup the problem:
    public interface VO<T, V> {
      public T getOid();
      public void setOid(T oid);
      public V getVersion();
      public void setVersion(V version);
    public interface CarVO extends VO<Long, Integer> {
      public String getPlate();
      public void setPlate(String plate);
    public class CarVOImpl implements CarVO {
      private Long oid;
      private Integer version;
      private String plate;
      public Long getOid() { return this.oid; }
      public void setOid(Long oid) { this.oid = oid; }
      public String getPlate() { return this.plate; }
      public void setPlate(String plate) { this.plate = plate; }
      public Integer getVersion() { return this.version; }
      public void setVersion(Integer version) { this.version = version; }
    public class Cool {
      public static void main(String[] args) {
        try {
          CarVO vo = new CarVOImpl();
          PropertyDescriptor[] properties = Introspector.getBeanInfo(vo.getClass()).getPropertyDescriptors();
          for (int i = 0; i < properties.length; i++) {
            System.out.println("Name " + properties.getName());
    System.out.println("PropertyType " + properties[i].getPropertyType());
    } catch (Exception e) { e.printStackTrace(); }
    Well. This code is 100% alright, compilation OK. In runtime, no matter what I do, inverting the generic types, modifying interfaces, whatever, the property with the first generic type defined (in this example, oid) will be wrong resolved to java.lang.Object, instead the correct java.lang.Long.
    Name oid
    PropertyType class java.lang.ObjectAltering the order of the getter and setter in the source code seems to affect the result of Introspector!!! (ahhhhhhh)
    This is probably a damm bug of Introspector class, that is private of Sun. Any idea to correct this problem?

    Hi,
    JSF 1.1 doesn't coexist nicely with HTML components.
    So if your goal is to build layouts in HTML then this
    will not produce the result you want
    Skins in 10.1.3 are slightly different than in 11
    (selectors may have changed their names). If you need
    to specify the class property to make skins work then
    this indicates that the skin selectors you use are
    not the correct ones.
    FrankHi Frank,
    thank you for your help, I'm replacing every html component with adf one, panelGroup, panelHorizontal, panelBorder, objectImage etc... etc... but I have a problem...
    I need to put an object component about Macromedia Flash and I cannot find any adf component to replace it. Any idea please?
    Thank you again.
    Ciao.
    Ricky

  • Requirements about delay and bandwith for using OTV in Nexus 7000 between two data centers separated 25 miles?

    We have two Nexus 7000, and I need use them with OTV between two data Centers separated 25 miles, but I don´t know what are the optimal values about bandwidth and delay (ms) for extended VLANs IDs (production and DAG replication) for Microsoft Exchange environment. Can somebody tell me please which are the values required for operate OTV in optimal conditions in this case? We have about 35 000 users that will use that platform of email. Thanks a lot for your comments. Regards.

    We have two Nexus 7000, and I need use them with OTV between two data Centers separated 25 miles, but I don´t know what are the optimal values about bandwidth and delay (ms) for extended VLANs IDs (production and DAG replication) for Microsoft Exchange environment. Can somebody tell me please which are the values required for operate OTV in optimal conditions in this case? We have about 35 000 users that will use that platform of email. Thanks a lot for your comments. Regards.

  • Long distance application failover between data centers.

    Hello:
    I am working a project where there is a requirement to have a primary server and a secondary for application failover. The requirements dictate that the servers must be geographically separate at separate data centers but yet on the same IP subnet so that heartbeat messages are not natively routed. What protocol can I use to bridge the subnet over an IP routed network? GRE? L2TP?

    GRE will not work as according to the last information I have you cannot bridge over a GRE tunnel. We had one such application with similar requirements and we ended up using L2TPv3 that allows transparent LAN extension. We have not had any issues with it and if you are only going to use it for heartbeats you should not run into any performance issues. L2TPv3 does tend to drive the CPU utilization high in case you have a lot of data traversing the tunnel.

  • DAG across 2 Data Centers

    Looking for pros and cons of 2 potential Exchange 2013 implementations.
    ADSite1: 400 users
    ADSite2: 100 users
    ADSite3: 50 users
    Implementation 1: (DAG across two Data Centers without DAC implemented)
    ADSite1: ExchSrv1 (MBX/CAS) --- DAG (2 DB) --- ADSite2: ExchSrv2 (MBX/CAS)
    ADSite3: FSW
    Implementation 2: (DAG across two Data Centers with DAC implemented)
    ADSite1: ExchSrv1 (MBX/CAS) ExchSrv2 (MBX/CAS)--- DAG (2 DB) --- ADSite2: ExchSrv3 (MBX/CAS)
    Site3: FSW
    1. Am I gaining any true benefit from Implementation 2 (additional server in Primary Site)? i.e. Implementation 1 covers me for HA and DR. Would it make sense to consolidate ADSite1 and ADsite2 into a single ADSite for Implementation 1?
    2. In either case, is it ok the configure NLB for all the servers (for the CAS role). So, if a user on ADSite2 hits the CAS on ADSite1 they could then be proxied to either ADSite ExchSrv depending on where their MBX is.
    3. If all the MBX DBs in ADSite2 are replicas and not active and a user hits the CAS on ADSite2, is this increasing network traffic to then allow ExchSrv3 (CAS) to have to proxy to the ExchSrv1 (MBX). If so, does it not make sense to have the ADSite2
    server only hosting replicas?

    Hello,
    1. I recommend you use Implementation 2. When you enable DAC mode, it will prevent split brain from occurring by including a protocol called Datacenter Activation Coordination Protocol (DACP). After a catastrophic failure, when the DAG recovers, it won't
    automatically mount databases even though the DAG has a quorum. Instead DACP is used to determine the current state of the DAG and whether Active Manager should attempt to mount the databases.
    2. You can deploy CAS NLB, but you can't depoly DAG+WNLB. If you deploy NLB, the CAS will proxy traffic to the Mailbox servers hosting the active copies.
    3. If you deploy NLB,  the ExchSrv3 (CAS) may proxy requets to the ExchSrv1 (MBX).
    Additional article for your reference.
    http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx
    Cara Chen
    TechNet Community Support

Maybe you are looking for